New platform migration program

# Timeline

Migration runs in batches, once the new platform leaves beta with feature parity. The pilot wave is planned for autumn 2026: newer Universal Apps, mostly in the US region, their setup being closest to what the new platform expects. Later waves take on older apps, larger setups and apps needing code or config work. Planned completion: 2027.

# Communication

Each batch is announced by e-mail and confirmed by another one once the apps have moved. Batches are opt-out: the owner can postpone to the next wave.

# Account migration

Matching accounts are created on the new platform, identity and billing carry over:

• companies → teams
• billing contacts → payment methods
• apps have environments now (at least one)

Login is planned to work on both platforms, setting a new password is required.

# App migration

Steps per app, once the account is in place:

1. Apps, environments and domains pre-created and pre-configured.
2. Code, files and database copied over.
3. Review by fortrabbit staff.
4. DNS switch (see below).
5. Old app deleted soon after.

# DNS switch

fortrabbit handles the DNS switch — no downtime, no interaction. A hop points the old CNAME-based app URL at the new test domain:

domain → {{appname}}.frb.io → {{env-id}}.{{region}}.frbit.app

Pointing the domain straight at the test domain afterwards removes that hop.

# After the migration

• New dashboard at dash.fortrabbit.com↗.
• The fortrabbit-hosted Git repository is gone. Deploy through the GitHub integration, or over SSH/SFTP/rsync.
• SSH/SFTP login with username and password is gone, SSH keys are required.
• SSH/SFTP host URLs changed, pick up the new ones from the dashboard.
• See platform changes for all details.

# Suggested next steps

• Review the app. We test migrated apps, but cannot know each code base.
• Download a fresh code backup from the new platform.
• Move deployment to the GitHub integration, the only Git host supported for now.

# Billing

Migration is free. The price level stays about the same, individual bills may vary. App plans map to the new components as closely as possible. Billing is in arrears per app on daily usage, so overlap stays minimal.

# Full migration

All apps moving at once: the migration month brings one invoice from each platform, after that only the new one.

# Partial migration

Some apps may stay behind, opted out or needing adjustment. Both platforms then invoice per app until the migration completes. Nothing is charged twice.

# Code/config adjustments

Apps kept up to date and configured with ENV variables need no changes. Otherwise we may adjust code or config: a composer update, a framework version bump, or hardcoded config values.

# No warranties

We do our best to ensure your migration is successful. We test ourselves as good as we can. But we can't guarantee everything will work perfectly without your input. You know your apps the best. Make sure to test your apps after migration.

Changes to account, app or content can get lost in the window between backup, install and DNS switch. We aim to keep that window short to minimize drift.

# Self-service migration

The self-service migration guide covers moving an app by hand: deploy the code base, import the database, copy the media library into persistent storage. This is the safest way to stay in control of your migration.

Please contact us at any point. We provide hands-on assistance and can offer a discount during the migration period.