Migrate a Wodby 1 app to Wodby 2

What the migration covers

The migration reproduces a compatible app on Wodby 2, transfers its supported configuration and data, and makes the cutover safer. It works best when:

• The source is a Wodby-managed Drupal or WordPress app and a compatible Wodby 2 stack is available.
• You want to preserve supported service states, custom runtime environment variables and secrets, cron schedules, routes and their HSTS policies, basic auth, repository settings, databases, and files.
• A snapshot-based data import is acceptable and you can account for writes made after the selected backup.
• You want a reviewed plan, resumable operations, and health checks around the cutover.

You can also leave code or data to your own process: ask the agent to skip code when your CI pipeline deploys it, or to skip data when you move databases and files with a separate tested procedure. When code is skipped, services that need it, such as Varnish in front of Nginx, wait until you deploy it. If files are imported into storage that a code service mounts, for example the NFS storage of a WordPress or Drupal app, the migration pauses before that import and names the service to deploy. Deploy it, then ask the agent to continue.

Primary path: managed Drupal and WordPress stacks

For a managed Drupal or WordPress app, the recommended default is a new app-specific stack duplicated from the compatible public Wodby 2 catalog stack. The migration configures that stack before it creates the app, and all selected instances of one source app reuse it. A server migration creates one new stack per source app, not one stack per instance or one shared stack for the server. The preview shows and pins the exact catalog stack revision, services, versions, build source, and import capabilities before apply.

• WordPress: use the compatible managed WordPress stack. The migration can transfer supported configuration, repository code, the database, and files/uploads.
• Drupal: use a compatible managed Drupal stack for the application's current major version. The migration can transfer supported configuration, repository code, the database, and public or private files exposed by the Wodby 1 backup.
• Forked managed Drupal or WordPress stacks: these remain on the managed migration path when their Wodby 1 metadata identifies the Drupal or WordPress family. The migration starts from the managed Wodby 2 catalog stack, transfers the fork's custom defaults, and adds exact mapped Wodby 2 services needed by the fork. Renamed or otherwise ambiguous additions need an explicit mapping, which the preview asks for.
• Fully custom stacks: choose a pre-created Wodby 2 stack and map every enabled service explicitly. The migration moves custom and default environment values to the mapped services, but does not recreate source images, ports, workloads, or volumes.

Choose an existing target stack only when you deliberately want it instead of the per-app catalog copy. The selected stack still has to pass the complete review; the migration does not silently modify an unrelated existing stack beyond the reviewed configuration.

Drupal 7 is blocked from the managed path. For Drupal-family stacks, the migration checks the effective NGINX_VHOST_PRESET value on the Wodby 1 nginx service. A preset such as drupal10 or drupal11 is used as the inferred Drupal major even when the original stack metadata still says Drupal 8 or 9. This inference is shown as a warning for confirmation. Drupal 8 or 9 remains blocked when the preset does not identify Drupal 10 or newer; if you confirmed that the application was upgraded, tell the agent so. The migration does not inspect application code or composer.lock, so you remain responsible for validating the real Drupal version before apply.

Database and files migration requires matching import capabilities in the target stack. Repository migration requires an enabled connect-build service; apps without a usable linked repository use the automatic Custom CI path. Same-name services map automatically when unambiguous, while renamed services need an explicit mapping. The built-in compatibility policy maps athenapdf to gotenberg, mailhog to mailpit, pma to phpmyadmin, redis to valkey, and varnish to vinyl. Wodby 1 sshd uses the target PHP SSH derivative. The infrastructure-only crond, rsyslog, and xhprof containers are not recreated; application cron entries become Wodby 2 service cron schedules. The preview lists each conversion with its source and target service, schedule, command, and resulting state, and lists every enabled source service that is intentionally not migrated, such as Apache when nginx replaces it, so the omission cannot be mistaken for an ordinary disabled service.

The preview also shows every source and target service version. A supported non-EOL source version is preserved. If it is missing, unavailable, disabled by the selected stack, or EOL, the migration highlights the choice and selects the highest supported non-EOL version. Review this as an application compatibility change, and ask the agent for another available version when you need one.

Paid features and free-tier behavior

The preview reads the subscription capabilities of the target organization. It shows features that can be staged safely as warnings and stops before target changes when a free-tier limit would make the planned app invalid. Review these results again if you change the target subscription before applying.

Review the current Wodby 2 stack catalog before planning. The migration selects the matching public catalog stack for the managed default, and the plan remains the final app-specific compatibility review.

Set up before you migrate

1. Create the organization and choose app ownership

Sign in to the Wodby 2 dashboard, then create or join the target organization. Your user must be an active organization owner or admin. When the selected cluster is project-owned, the migration defaults the app to that cluster's owner project. An organization-owned cluster defaults to an organization-owned app. Name another project only to choose a different project with access to the cluster. Do not pre-create the app itself: the migration creates it, and an unrelated app with the Wodby 1 app name is a blocker.

The selected stack, cluster, and Git or registry integrations must be compatible with the app's ownership. An organization-owned app must use organization-owned resources. A project-owned app can use resources available to that project. Keep the same ownership choice for preview, apply, and verify.

2. Create a cluster

Finish provisioning a cluster before the preview, and wait until it is ready for app deployments. Choose the model that matches where you want the infrastructure to run:

• Wodby Cloud for a persistent Wodby-hosted cluster and the simplest start.
• Managed Kubernetes when the cluster should run in your supported cloud-provider account and Wodby should provision the Kubernetes layer.
• Self-hosted Kubernetes for a lower-cost single-server deployment on your server or VM.

The migration uses these existing resources; it does not move infrastructure from Wodby 1. For a production migration on Wodby Cloud, use a persistent cluster rather than a temporary demo cluster.

3. Connect Wodby 1

1. In the Wodby 1 dashboard, create an API key under Account > API Keys as an owner or admin of the Wodby 1 organization. A key scoped to one organization lets the migration see that organization only.
2. In the Wodby 2 dashboard, add an integration with the Wodby 1 provider and enter that key. Never paste a key, password, or token into a chat: a chat keeps what is written in it.

Keep the same key for the whole migration. Protected values the migration needs, such as secret variables and relay credentials, are read with it and passed directly to Wodby 2.

4. Connect Git for Wodby CI

The recommended path for an app deployed from a repository uses Wodby CI. Add a Git integration in the target organization and authorize access to the source repository. The migration finds the repository by the name in the Wodby 1 repository URL and links it while configuring the target app; you do not need its provider-specific ID. Wodby CI builds the branch, tag, or commit that Wodby 1 deployed, unless you ask for another.

For Wodby CI, the repository needs .wodby/pipeline.yml at every selected Git ref; a missing pipeline is a blocker. If the integration does not expose the repository, the preview warns and continues without a repository link, using Custom CI. When the repository has a different name in the integration, or lives on another Git host than the integration's provider, for example a self-hosted GitLab server, give the agent its exact name: a repository with the same name on another host may be a different one, so the preview blocks until you confirm it.

5. Optional: add the other integrations you want to use

A CI integration such as CircleCI, a storage integration for backups, or a mail provider integration. Wodby Agent tells you when one of your choices needs an integration that does not exist yet, and you add it in the dashboard.

# After downloading and extracting the release archive on Linux or macOS:
sudo install -m 0755 ./wodby /usr/local/bin/wodby

# Confirm that this version contains the migration command.
wodby version
# The reported Wodby CLI version must be 2.12.0.
wodby migrate wodby1 instance --help
wodby migrate wodby1 app --help
wodby migrate wodby1 server --help

Choose how the app is built and run

The preview keeps your Wodby 1 setup by default. Wodby Agent offers the Wodby 2 options below, each with what it gives you; none is required. Each answer changes the plan, and the agent previews it again before it asks to start.

• Builds: an app deployed from a linked repository uses Wodby CI. An app that Wodby 1 built with third-party CI can keep that CI through a Wodby 2 CI integration, optionally with the repository linked, or switch to Wodby CI. Without a CI integration, the migration uses Custom CI.
• Development workspaces: a dev or staging instance deployed from Git can become a workspace.
• Certificates: a route with a custom certificate can use Let's Encrypt instead, issued and renewed automatically once DNS points to Wodby 2.
• Backups: keep them in Wodby Blob storage, or in your own S3, GCS, Azure, Wasabi, or Backblaze storage, and choose the daily automatic backup window, 30 to 180 minutes in the organization's time zone.
• Mail: relay through a mail provider integration you already use, also for instances that sent mail without a relay, and deliver the mail of staging, test, and development app environments to the stack's Mailpit service, so testing never emails real recipients. Production keeps its delivery.

# One instance: add --workspace to the arguments used for Wodby CI.
wodby migrate wodby1 instance "${migration_args[@]}" --workspace

# One app: name each instance that should become a workspace.
wodby migrate wodby1 app SOURCE_APP_UUID --target-cluster TARGET_CLUSTER \
  --target-git-integration-id TARGET_GIT_INTEGRATION_ID \
  --workspace-instance dev

# One server: qualify the instance name with its app.
wodby migrate wodby1 server SOURCE_SERVER_UUID --target-cluster TARGET_CLUSTER \
  --target-git-integration-id TARGET_GIT_INTEGRATION_ID \
  --workspace-instance example/dev

# Only when the cluster has no single default storage class:
#   --workspace-storage-class STORAGE_CLASS
# or keep the files on an enabled storage service of the stack:
#   --workspace-storage-service STORAGE_SERVICE

# After apply, show the SSH connection details of the new app environment.
wodby app environment workspace connection ENVIRONMENT_ID

# Wodby 2 external CI initializes against the buildable app service ID.
wodby ci init "$WODBY_APP_SERVICE_ID"

# Use this form instead when the runner builds through Docker-in-Docker.
wodby ci init --dind "$WODBY_APP_SERVICE_ID"

# A source using deployment type "ci", or a migration without a usable linked
# repository, automatically gets a create-or-reuse Custom CI integration.
# Optionally select a specific existing target CI integration instead:
migration_args+=(
  --target-ci-integration-id TARGET_CI_INTEGRATION_ID
)

# Or move the instance to Wodby CI, which builds from the linked repository.
# The repository needs .wodby/pipeline.yml; the preview says when it is missing.
# migration_args+=(
#   --target-wodby-ci
#   --target-git-integration-id TARGET_GIT_INTEGRATION_ID
# )

Operational checklist

• Choose the source instance, app, or server. Wodby Agent lists what your Wodby 1 key can migrate. Make sure the instance, its parent app, services, routes, and available backup components are stable.
• Decide which successful backup to import, who will test and approve the imported app, change DNS, and approve rollback or completion.
• Lower DNS TTL ahead of time when practical, and reserve a cutover window that includes any optional final backup, import time, DNS propagation, route deployment, and certificate issuance.

Keep Wodby 1 intact throughout the migration and for an agreed rollback window afterward. If Wodby 2 accepts writes after cutover, the rollback procedure must account for those new writes.

wodby migrate wodby1 instance SOURCE_INSTANCE_UUID \
  --target-app TARGET_APP_ID \
  --target-cluster TARGET_CLUSTER

wodby migrate wodby1 app SOURCE_APP_UUID --target-cluster TARGET_CLUSTER [target and mapping options]
wodby migrate wodby1 app SOURCE_APP_UUID --target-cluster TARGET_CLUSTER [same options] --apply
wodby migrate wodby1 app SOURCE_APP_UUID --target-cluster TARGET_CLUSTER [same options] --verify

# One reviewed plan for every app hosted on the source server.
server_args=(
  SOURCE_SERVER_UUID
  --target-cluster TARGET_CLUSTER
  # The API key selects the target organization. Optionally add
  # --target-project TARGET_PROJECT to override the cluster ownership default.
  --target-env-map prod=prod
)

# If every repository is visible through one integration, the CLI derives and
# looks up each repository name automatically.
server_args+=(
  --target-git-integration-id GIT_INTEGRATION_ID
)

# Use per-app mappings only for a different integration or name override:
# --target-repository-map 'SOURCE_APP_UUID=GIT_INTEGRATION_ID'
# --target-repository-map 'OTHER_APP_UUID=GIT_INTEGRATION_ID:OWNER/OTHER_REPOSITORY'

# Omit Git options for automatic Custom CI. Add --skip-code only when code
# delivery is intentionally outside the migration.
# Preview every app. Add --apply only after reviewing the full output.
wodby migrate wodby1 server "${server_args[@]}"

1. Preview the migration

Open Chats in your Wodby 2 organization and ask Wodby Agent to migrate the instance, naming the Wodby 2 cluster, for example:

Migrate the prod instance of my Wodby 1 app example to the cluster main.

The agent finds the source with your Wodby 1 integration, previews the plan, and explains every blocker and warning in plain words. It asks before anything that only you can decide and offers the options from Choose how the app is built and run. Read every review item: migration details, warnings, the enabled services that will not be migrated, and blockers. Warnings include safe target downgrades such as cron schedules or automatic-backup presets staged disabled because of the target subscription.

Resolve all blockers before you start: each one names the decision it needs, such as an environment type, a stack, a service, a version, or an import mapping, and the agent previews again with your answer. The approved plan pins the immutable target stack revision and the exact target service, integration, build, import, and Wodby 1 backup identities, so later catalog changes or newer source backups cannot silently substitute a different revision or snapshot. A started migration refuses a changed source configuration or changed choices; to change a choice, ask the agent to preview again and restart it.

# Load these through your secret manager before running the command:
# WODBY1_SOURCE_TOKEN
# WODBY_API_KEY

# Bash/Zsh array: define the common arguments once.
migration_args=(
  SOURCE_INSTANCE_UUID
  --target-cluster TARGET_CLUSTER
  # The API key selects the target organization. Optionally add
  # --target-project TARGET_PROJECT to override the cluster ownership default.
  --target-env-map prod=prod
  --wait-timeout 60m
)

# Recommended when the source repository is available: use Wodby CI.
# Select the Git integration that exposes the source repository.
migration_args+=(
  --target-git-integration-id TARGET_GIT_INTEGRATION_ID
  --target-git-ref main
  --target-git-ref-type branch
)

# The CLI derives owner/repository from the Wodby 1 repository URL and looks
# for that exact name in the selected integration. If the names differ, add:
# --target-repository-name 'OWNER/REPOSITORY'

# Preview only. This does not create local files or change either platform.
wodby migrate wodby1 instance "${migration_args[@]}"

--target-env-map SOURCE_TYPE=TARGET_TYPE
--target-app EXISTING_TARGET_APP_ID
--target-stack-id EXISTING_TARGET_STACK_ID
--target-stack-map '[APP/][INSTANCE/]SOURCE_STACK=TARGET_STACK_ID'
--target-service-map '[APP/][INSTANCE/]SOURCE_SERVICE=TARGET_SERVICE'
--target-version-map '[APP/][INSTANCE/]SOURCE_SERVICE=TARGET_VERSION'
--target-import-map '[APP/][INSTANCE/]COMPONENT=TARGET_SERVICE:TARGET_IMPORT'

2. Review or choose the source backup

The migration does not create a Wodby 1 backup. By default it selects the newest successful file for each required component of every included instance. Database and files can therefore come from different successful backups when the newest backup contains only one component. The preview shows each component's backup, its completion time, size, and target import, and warns when one instance uses mixed snapshots. There is no maximum backup-age requirement and maintenance mode is not required. Ask the agent to import another successful backup when you need a different one.

An explicitly selected backup must belong to the source instance, be successful, and contain every required component; it pins all components to that one snapshot. Automatic selection instead pins every component independently to a successful backup file. Every selected file must be available through HTTPS. The migration pins those exact backups before making target changes and reuses them even if Wodby 1 creates a newer backup later.

Optional: minimize writes after the snapshot

Changes made after the selected backup completed are not migrated. If that gap matters, optionally enable maintenance mode from Instance > Stack > Settings in Wodby 1, create a backup manually, wait for it to succeed, and ask the agent to preview again. The new backup then becomes the default. Keep maintenance mode enabled until cutover if your process requires a write-free migration window. Enabling maintenance mode does not create a backup; the Wodby 1 backup action remains manual.

# One instance: import a specific successful backup.
migration_args+=(--source-backup BACKUP_UUID)

# One app: override selected snapshots by instance.
wodby migrate wodby1 app SOURCE_APP_UUID --target-cluster TARGET_CLUSTER \
  --source-backup prod=PROD_BACKUP_UUID \
  --source-backup dev=DEV_BACKUP_UUID

# One server: qualify instance names with the app.
wodby migrate wodby1 server SOURCE_SERVER_UUID --target-cluster TARGET_CLUSTER \
  --source-backup example/prod=PROD_BACKUP_UUID

3. Start the migration and import the selected data

When the plan has no blockers, the agent summarizes it and asks whether to start. After you approve, the migration runs as a task that you can follow on its task page or by asking the agent how it is going. It creates and publishes the app-specific stack configuration, resolves reusable integrations, creates the app and app environment, reconciles supported service states and routes, creates route auths for protected custom domains and the replacement technical domains, then deploys and imports data. With Wodby CI it also connects, builds, and deploys the reviewed Git source. If the migration pauses, for example until your third-party CI pipeline runs once, the agent tells you what to do; then ask it to continue.

For a Wodby 1 domain with custom TLS, the preview looks for an active Wodby 2 custom certificate in the target organization that covers the exact hostname, including a matching wildcard name. If exactly one is found, the plan pins and attaches it without reading or exporting its private key. The basic-auth password is transferred only in memory. If the target organization has no paid custom-domain entitlement, each custom domain is staged disabled.

Imports run one component at a time. Before each one, the migration refreshes the Wodby 1 export to get a current download address for the selected backup and confirms that the protected configuration and selected snapshot have not changed. Download addresses are not saved with the plan; Wodby 2 keeps one only while its import runs. Keep the selected source backup until verification and the agreed rollback window are complete. The imported snapshot stays fixed even if Wodby 1 accepts newer writes; those writes are not migrated.

Migrated cron schedules stay disabled after apply, so scheduled jobs such as mail, payments, or syncs with external systems do not run on Wodby 1 and Wodby 2 at the same time. Verification enables them once DNS points to Wodby 2.

The first deployment runs before the data import, so post-deployment scripts such as drush deploy may fail on the empty database. The migration reports this as a warning and continues. If your application needs those steps after the import, run them once on the technical URL.

# The preview shows the selected backup UUID, completion time, components,
# and size. Rerun the reviewed command with --apply. No plan hash is required.
wodby migrate wodby1 instance "${migration_args[@]}" --apply

# Apply asks for interactive confirmation. For an intentionally unattended
# invocation, add --yes after reviewing the same preview in advance.
# wodby migrate wodby1 instance "${migration_args[@]}" --apply --yes

# Test the imported app on its technical URL. Change DNS only after it passes.
# Once every hostname resolves to Wodby 2, verify the performed migration.
wodby migrate wodby1 instance "${migration_args[@]}" --verify

Final acceptance gate before DNS

Do not change DNS as soon as the migration is applied. Open the Wodby 2 technical URL and confirm that the app is running with the final imported database and files. DNS should be the last customer-controlled action that sends production traffic to the new platform. Wodby Agent lists these steps when the migration is applied.

• Confirm every enabled service is healthy and the approved Git ref is deployed with no pending rebuild or redeploy.
• If custom domains were staged disabled on a free plan, upgrade the target organization and enable those domains before changing DNS. Wodby checks the paid entitlement again when each domain is enabled.
• For every Wodby 1 custom-TLS domain, confirm that the preview named the Wodby 2 certificate to attach. If no certificate—or more than one—matches, add a custom certificate in Wodby 2 and attach it to the migrated route before changing DNS, or ask the agent to use Let's Encrypt instead. Private keys are never transferred from Wodby 1.
• Search indexes are not migrated: Wodby 1 backups contain the database and files only. If the app uses Solr, Elasticsearch, or OpenSearch, reindex its content on Wodby 2, for example with drush search-api:index, and test search.
• Mail sent while you test goes out through the migrated mail settings, unless test environments deliver it to Mailpit. Use test accounts, and avoid actions that send mail to real users.
• For Drupal, test administrative login, database-backed content, public and private files, caches, and the configuration of cron, queues, mail, and external integrations.
• For WordPress, test administrative login, pages and posts, media, permalinks, plugins, and the configuration of scheduled tasks, mail, and external integrations.
• Confirm the migration owner, application owner, and DNS owner agree that the target is ready, and that the rollback procedure and monitoring are ready before approving cutover.

Keep acceptance checks read-only where practical. If a test writes to Wodby 2, remove the test data or explicitly account for that write in the rollback plan. Do not re-enable writes on Wodby 1 or replace the snapshot after data synchronization has started.

4. After acceptance, change DNS

After the final acceptance gate passes, change each custom hostname to the selected Wodby 2 cluster using the records appropriate for that cluster. The migration does not change DNS. Wait until public resolution returns the target cluster before you ask the agent to verify.

If a hostname is proxied through a CDN or DNS provider, switch its record to DNS-only or otherwise bypass the proxy for cutover. Verification needs direct public DNS resolution to return the target cluster addresses. Re-enable the proxy only after the routes and certificates are ready and your tests pass.

Verification refuses to complete while a hostname resolves outside the selected cluster. Let's Encrypt certificates can only be issued after the hostname reaches the target, so include certificate time in the maintenance window. During DNS propagation, some visitors may still reach the maintenance-mode Wodby 1 app.

Once traffic has moved, disable the cron jobs of the Wodby 1 instance so they stop running against the old data. Enable them again only if you roll back to Wodby 1.

5. Verify and complete

Ask the agent to verify the migration. Verification checks that DNS resolves to the selected cluster, reads the target app back, and validates the app and app environment relationships, service state, migrated environment variables, cron schedules, routes, authentication, certificates, completed imports, and workload status. It enables the migrated cron schedules before it checks them, and marks the migration complete only after all checks pass.

Verification confirms each expected route auth by its scope and login, but cannot compare write-only secret values or basic-auth passwords. Repeat the critical checks through the production hostnames, confirm HTTPS certificates, redirects, route protection, indexing rules, scheduled jobs, mail, and external integrations, then exercise controlled writes and create a Wodby 2 backup. Keep Wodby 1 for the agreed rollback window; the migration does not delete it.

Resume safely after an interruption

The migration records checkpoints, so an interrupted run continues where it stopped and does not repeat completed operations. Ask the agent to continue it. To start over with new choices instead, ask it to preview again and restart: the migration first removes what it created in Wodby 2, keeping apps and integrations that existed before. A restart is refused after successful verification and while the result of an operation is uncertain.

If a network interruption makes a create operation uncertain, the migration stops rather than risk creating a duplicate. On resume it can adopt only one uniquely matching resource created in the same time window. If that is not possible, check Wodby 2 for the resource; once you are sure the original operation did not take effect, ask the agent to retry exactly that operation.

# Normal recovery: preserve the applied plan and completed work.
wodby migrate wodby1 instance "${migration_args[@]}" --apply

# Start over: the CLI lists what it will remove first and asks to confirm.
wodby migrate wodby1 instance "${migration_args[@]}" --apply --restart

Roll back a migration you decided not to keep

If you decide against a migration before DNS cutover, ask the agent to roll it back. Rollback removes what the migration created in Wodby 2, and the dashboard asks you to confirm twice. Wodby 1 is never touched.

It deletes only what the migration recorded creating: the app it created, together with every app environment, service, route, and imported database and files under it; the stack it generated for that app; and the integrations it created. If you added the instance to an app that already existed, that app is kept and only the app environments the migration added are removed. Integrations it reused rather than created are kept, because other apps in the organization may depend on them. Rollback also lists what it leaves in place for you to remove: a custom variable provider created for shared variables, which other migrated apps may use, and configuration added to a stack that existed before the migration. Deletion follows Wodby 2's dependency order, and resources that are already gone count as success, so an interrupted rollback can be run again.

wodby migrate wodby1 instance "${migration_args[@]}" --rollback

Blockers that require a decision

• Missing or inactive organization owner or admin membership on either side.
• Target project (when selected or inferred), cluster, environment type, stack, service, or import mappings that are missing, inconsistent, or ambiguous.
• An unrelated Wodby 2 app with the exact source app name. A resumed migration can reuse only the app it created. For a one-instance migration, choose an intended existing app explicitly.
• A selected target app that has incompatible organization or project ownership, has no unambiguous stack, or already contains an app environment with the source instance name.
• A repository selected for Wodby CI without .wodby/pipeline.yml at the selected Git ref. A missing repository match itself is a warning and switches that app to unlinked Custom CI.
• A fully custom or unrecognized Wodby 1 stack without an explicit Wodby 2 stack and service mapping. A fork whose metadata identifies Drupal or WordPress instead uses the managed path described above.
• A target free-plan app-service allowance that is smaller than the enabled service count required by the migration.
• Unsupported custom service configuration. The migration blocks rather than guess how a Wodby 1 override should translate.
• A variable set to an empty value in Wodby 1 when the Wodby 2 service or stack sets its own value for it.
• Redacted SMTP or S3 secrets, inconsistent relay values that cannot be scoped by environment type, an unsupported backup mirror provider, or an S3 backup preset on a target plan without automatic-backup support.
• Invalid cron entries, unstable source resources, missing backup components, or a selected backup that is failed or internally inconsistent.
• Wildcard, unresolved, or CDN-proxied custom hostnames that cannot pass direct-resolution DNS safety checks.

Resolve blockers and preview again before you start. If target resources have already been created, keep the migration and ask the agent to restart it with the new choices, or contact Wodby support, before attempting a different plan.