Field guide
Plan a safe app migration
Moving systems is a business change. Treat it that way.
Define what moves
List the records, files, history, templates, integrations, and permissions that must move. Classify each as required at launch, useful later, or archive-only.
A migration can fail even when data imports correctly if the team loses the current job list, customer context, or approval history they need on day one.
Run a small rehearsal
Use a limited set of real but noncritical records when permitted, or representative test data. Check totals, statuses, files, links, and the workflow the team will actually use.
Write down what is not moving and where it will remain. Unclear gaps become emergency work after launch.
Set a cutover rule
Choose the date or condition when new work starts in the new system. Name who can approve a rollback and how the team will communicate during the change.
Keep the old system accessible only as long as it serves a defined purpose. Parallel use without a deadline creates two competing versions of the business.