Prepare an App for migration

Prepare the source App before copying production data. The goal is to make the move repeatable and to keep the final change window short. Use the migration readiness checklist to track completion.

Record the source environment

Create an inventory of:

• the framework and exact runtime versions;
• the current code location and intended Git or Workspace deploy source;
• database size and version;
• uploaded media and other persistent files;
• domains, redirects, certificates, and DNS records;
• scheduled jobs and background workers;
• environment variables, secret names, and external integrations;
• email, payment, search, cache, and storage dependencies.

Don’t copy secret values into the inventory. Record each secret’s purpose, owner, and rotation procedure instead.

Make the code reproducible

Choose the deploy source you will use for migration:

• Git: put the production code in the repository you will connect to synsmarts. Remove machine-specific files, generated caches, and credentials. Confirm that a clean checkout installs and starts without untracked files: clone the repository into a fresh directory, install dependencies from the committed manifests, and start the application there. Anything the app needs that isn’t in the repository surfaces at this step instead of during migration.
• Workspace: prepare a repeatable transfer into the synsmarts Workspace. Exclude machine-specific files, generated caches, runtime data, and credentials. Confirm the transferred tree contains every required project file. For Magento, preserve the production vendor/ tree when it is the available complete dependency source; synsmarts validates it before reuse.

Git is recommended when you need durable review history. If the source App has direct production edits and you choose Git, reconcile them into the repository before migration.

Choose the target App

Create an App with a resource shape that can hold the current workload and its expected near-term growth. Match supported runtime and service versions before attempting an upgrade as part of the move.

Plan the final change window

Choose a period when writes and administrative changes can pause. Lower DNS time-to-live values far enough in advance for the old value to expire before cutover.

Define:

• who can place the source App in maintenance mode;
• who will perform the final data copy;
• who can update DNS;
• what tests must pass;
• the point at which you will return traffic to the source.

Take a source backup

Create and verify a current source backup before the first copy. Keep it separate from any backup created during final cutover.

Continue with Move code and data.