Skip to main content

Migration and Onboarding

A migration is a separate technical engagement unless the Order includes it. The migration scope should identify the source, destination, data and functions to be moved, testing responsibility, cutover plan, and accepted limitations.

Information to Gather

  • domain registrar and authoritative DNS access;
  • source hosting or server access;
  • application and database versions;
  • repositories, build commands, environment configuration, and scheduled jobs;
  • storage locations, uploads, media, and generated files;
  • email routing and third-party integrations;
  • current traffic patterns and a preferred cutover window;
  • known defects, customizations, licensing constraints, and unsupported software; and
  • a current independent backup and a responsible person who can verify it.

Share credentials only through the secure method agreed for the migration. Create temporary or individual access when the platform supports it.

Migration Sequence

  1. Discovery — Confirm the source environment, supported workload, data, dependencies, and acceptance criteria.
  2. Destination setup — Provision the server and required runtime identified in the Order.
  3. Initial copy — Transfer the in-scope files, database, and configuration. This copy is not an ongoing backup service.
  4. Testing — Verify agreed pages, forms, authentication, checkout, integrations, jobs, redirects, and administrative access.
  5. Cutover preparation — Confirm DNS changes, data-freeze or final-sync plan, launch authority, and rollback decision.
  6. Cutover — Perform the approved DNS and final data steps.
  7. Verification and handoff — Check the agreed production functions, record known issues, and remove temporary access when appropriate.

Downtime and DNS

Downtime and DNS propagation cannot be guaranteed. They depend on the source architecture, data synchronization method, TTLs, resolvers, third parties, and the application’s ability to run in parallel. The migration plan should document the expected impact and rollback limits for the specific workload.

Customer Approval

The customer must provide an authorized launch contact and promptly test business-critical functions. Do not terminate the former service until the migration has been verified and the required rollback period, if any, has passed.

Review common source scenarios →