Before you begin
Create a copy or migration branch and keep the live application unchanged.
Document environment variables, integrations, databases, scheduled jobs, and the critical user workflow.
Migrate without disrupting the live app
A live migration should have two separate moments
Build and test the new version
Switch users to it
Do not combine them.
Use this sequence
1. Keep the existing production app live.
2. Create a copy or migration branch.
3. Import and run the new version in a separate environment.
4. Compare the main workflows.
5. Test login, data, integrations, and background jobs.
6. Prepare production credentials and monitoring.
7. Decide the exact switch and rollback steps.
8. Move traffic only when the new version is ready.
9. Keep the old environment available until the release is stable.
Your customers should experience a planned release, not your migration work.
If the app handles real money, regulated data, or a large user base, involve an engineer in the initial production switch.
Common mistakes
Building and switching users in the same step.
Migrating without a rollback plan.
Failing to test login, data, integrations, and background work separately.
Frequently asked questions
Does migration require downtime?
Not for the build and test phase. Keep the current application live and switch users only after the migrated version is verified.
What if the first import is incomplete?
Treat the import as a starting point. Identify what transferred, what depends on the old environment, and what should be translated or rebuilt more robustly.