Platform Migration Checklist: How to Switch Without Downtime

Platform migrations are the most underestimated projects in technology. A migration that 'should take 4 weeks' routinely takes 12. The reason: every migration surfaces hidden complexity. Data that looked clean has edge cases. Integrations you forgot about break. Team workflows change in ways nobody anticipated.

Phase 1: Discovery (2 weeks). Audit everything: data schemas, integrations, automations, user workflows, permissions, and edge cases. Document what the current system does, not what it was designed to do — these are often different. Map every integration, including the ones that 'just work' and nobody thinks about.

Phase 2: Parallel Build (4–8 weeks). Build the new system alongside the old one. Import data, configure integrations, and set up automations. Run both systems simultaneously. Compare outputs. When they match consistently, you're ready for cutover. This is the phase people skip. Don't skip it.

Phase 3: Controlled Cutover (1 week). Switch a small group of users first (canary release). Monitor for issues. Expand gradually. Keep the old system running in read-only mode. Have a documented rollback plan that can be executed in under 30 minutes.

Phase 4: Stabilisation (2 weeks). Monitor everything intensively. Fix issues as they surface. Gather user feedback. The first two weeks after cutover will reveal problems that testing didn't catch. Budget time for this explicitly.

The most dangerous words in a migration: 'We'll figure it out during cutover.' Every decision should be made before cutover weekend. Every script should be tested. Every rollback path should be documented and rehearsed.