Migrating Apps From the Common Runtime to a Private Space
Last updated April 27, 2023
This guide helps you migrate your apps from the Common Runtime to Private Spaces with minimal downtime. You can’t directly transfer an app from the Common Runtime to a Private Space. Due to the architectural differences in the runtime infrastructure, you must manually migrate your apps. The steps in this guide apply to both Private Spaces and Shield Private Spaces.
Heroku Enterprise customers with Premier or Signature Success Plans can request in-depth guidance on migration from the Customer Solutions Architecture (CSA) team. Learn more about Expert Coaching Sessions here or contact your Salesforce account executive.
Before the Migration
Configure a Custom Maintenance Page
Configure a custom page on your Common Runtime app to show to users during maintenance mode while your app migrates.
Plan For Downtime
Reduce the TTL values for your DNS entries to 1 minute a few days before the migration to minimize downtime. The migration process includes updating your DNS entries to point to the new app running in the Private Space. Plan for some downtime to allow for DNS updates to propagate.
Migrating data to private-tier data services also requires a period of downtime.
Review Add-ons Availability and Requirements
You must reprovision your add-ons on your migrated apps. Add-ons offer varying levels of availability for Private Spaces. Consult the Add-ons Runtime Availability table to check for potential issues.
Available: These add-ons are compatible with Private Space regions, but get provisioned and operate outside of the space. Network traffic between your private dynos and the add-on resource sends across the public Internet.
Available and installable in space: These add-ons are provisioned within the space itself. All network traffic between dynos and the add-on resource stays within the private network environment.
Unavailable: These add-ons can neither be provisioned within the space, nor are they compatible with the Private Space region(s).
Consider also that Private Spaces has features that replace the functionality of some add-ons. For example, if you used an add-on to provide static IPs in the Common Runtime, you no longer need it as that’s a built-in functionality of spaces.
Consult the documentation for each add-on, as the provider may have specific instructions for the best method of migrating to Private Spaces.
You can read more about using add-ons in Private Spaces here.
The Migration Process
The following steps describe the typical migration process. You can also follow these steps, with some minor modifications, to migrate apps from Private Space to Private Space, or from a Private Space to a Shield Space.
- Create a new application in the Private Space.
- Deploy your code to your new Private Spaces app using the same methods you used for the Common Runtime.
- Provision your add-ons and scale your dynos. If you used a Heroku button or the Platform API with an app.json manifest file to deploy your code, your add-ons and dynos were already automatically configured.
- If you use Heroku data services, it’s recommended that you migrate your data. While it’s possible for an app in a Private Space to continue using Heroku data services in the Common Runtime, migrating them to a space provides additional security.
- Heroku Postgres: To minimize downtime, use the follower changeover method. This method allows your existing database to continue operating while the new private database provisions. Dataclips that associated with the old database must be reassigned to the new database. To recover these dataclips, open a support ticket via help.heroku.com.
- Heroku Data for Redis: Use the fork method to migrate while your app is in maintenance mode.
- Heroku Kafka: Follow these instructions to migrate while in maintenance mode.
- Configure custom domains and SSL. Certain apps can have the same domain temporarily assigned to both your existing Common Runtime and new Private Spaces apps to reduce migration downtime. Contact Heroku Support to request that your custom domains be “forced” onto your new Private Spaces app. If they confirm that it isn’t possible, remove the custom domains from your Common Runtime app and add them to the new Private Spaces app.
- Update your DNS entries to point to the new Private Space app. If you reduced the TTL value before migration, you can restore it to normal.
- Monitor your new Private Spaces app. Monitor your app logs for any errors, and check your metrics for any signs of performance issues.
If you migrated your Postgres databases, ensure you contacted support to associate your dataclips from your old databases to the new ones before you delete any databases.
If you didn’t migrate your data services and they’re still attached to your Common Runtime app, don’t delete the old app. If you do, the attached databases get deleted along with the old app.
When you’re satisfied that the migration completed successfully, destroy the old Common Runtime app.