Confirm Migration Readiness

Confirm Migration Readiness

A migration should not enter connection setup or configuration until the account, purchased service, store access, scope, target environment, validation plan, and security responsibilities are ready. Confirming those conditions first prevents avoidable setup delays and makes later validation decisions traceable.

Start from the service you purchased

A purchased Next-Cart migration includes one fixed migration path, a selected service (Standard Migration, Managed Migration, or Custom Migration), an Entity Points Plan, optional Add-ons, and a 12-month active period beginning when the New order payment is successfully confirmed. If the migration has been extended, confirm the Expires value before preparing access or configuration.

Prerequisites

Before you begin, make sure you have:

Requirement	What to confirm
Next-Cart migration access	You can open the purchased migration from your own account as the owner or through Delegate Access.
Purchased service details	You know the migration path, Migration Service, Add-ons, and Entity Points Plan.
Source store access	You can access the source store or the person who owns source access is available.
Target store access	You can access the target store and confirm it is the correct environment.
Decision owner	Someone can approve scope, configuration choices, and acceptance criteria.
Validation owner	Someone can review migrated data and confirm pass or fail results.
Support contact	Someone can respond to Next-Cart support questions during setup and validation.

Preparation checklist

1. Confirm the migration path.

   Review the selected Source Platform and Target Platform in your order or in My Migrations. To reach it, expand Migrations in the Dashboard and select My Migrations. Do not continue if the path does not match the stores you intend to use.

2. Review the purchased service details.

   Confirm the Migration Service, purchased Add-ons, Entity Points Plan, payment status, and service expiration.

3. Confirm source store readiness.

   Make sure the source store is accessible and stable. Avoid major source-store updates, bulk catalog edits, database repairs, or app changes while preparing migration work.

4. Confirm target store readiness.

   Make sure the target store is accessible and prepared for validation. Confirm baseline settings that affect validation, such as language, currency, tax mode, shipping framework, and required platform apps or modules.

5. Identify required access owners.

   Confirm who can provide admin access, API credentials, hosting access, exported source data files, or other setup details if Next-Cart shows that they are required for your selected platforms.

6. List the data types you need to migrate.

   Identify the data types required by the project. When CSV, XLS, or XML is the Source Platform, the included file workflow migrates Products only; any additional entity type must already be part of the approved Custom scope developed for that migration.

7. Identify non-standard requirements.

   Document custom fields or database columns whose required handling exceeds supported mapping, third-party app or plugin data, unusual product structures, special order workflows, custom customer groups, subscription data, or any other requirement not represented by standard data selection or purchased Add-ons.

8. Define validation ownership.

   Decide who will review migrated products, customers, orders, content, redirects, and target-store behavior. Validation should include representative records, not only record counts.

9. Prepare security cleanup.

   Plan how temporary credentials, API tokens, social account access, hosting credentials, and KitConnect files will be revoked, rotated, or removed after migration work is complete.

Plan source and target activity during migration

Connection methods, platform behavior, migration scope, and target-side processing differ by path. Treat uninterrupted operation and source-store stability as requirements to plan and verify, not as blanket assumptions.

Area	Readiness rule
Source Store	Keep the source accessible and stable. Avoid bulk catalog edits, database repairs, application changes, or other major changes that can move the validation baseline while migration work is being prepared or checked.
Ongoing source activity	If the business continues taking Orders or changing catalog data, define the source-data cutoff and the intended additional-data handling before execution. Newly added records and updated existing records are not the same source window.
Target Store	Limit manual edits, imports, application writes, and other changes to the affected target scope while migration results are being validated. Otherwise it can become unclear whether a difference came from migration processing or later target activity.
Storefront availability	If uninterrupted selling or a specific downtime limit is a must-pass requirement, confirm the operating plan for the exact Source-to-Target path before execution. Do not rely on a universal no-downtime assumption.
Final pre-launch pass	Decide which Continue action, data selection, and Additional Options represent the required additional-data scope. Use additional-data processing when additional new Source data must be transferred; do not treat it as an automatic or bidirectional synchronization channel.

Keep the requirement path-specific

A migration can read and write different systems through different connection methods. When a source-impact, target-impact, or availability requirement is critical and the documented path does not establish the behavior explicitly, confirm it through Support Tickets before the migration window is approved.

Control target notifications before importing Orders

Imported historical Orders can interact with platform notification settings and third-party automations. Review the Target Store’s notification behavior before an Order migration so customers and staff do not receive unintended messages while historical data is being created or validated. Restore the intended live-store notification behavior only after the migration result has been reviewed.

Shopify notifications

Customer notifications are disabled by default during the documented Shopify migration workflow. Before importing Orders, disable third-party shipping and email-notification apps that could react to imported Orders. When creating the Shopify custom app used for the migration, do not enable Storefront API.

If customer Order notifications are still being sent, verify that Storefront API is disabled for the custom app and recheck any third-party shipping or email applications that can trigger messages from imported Orders.

Shopify staff/admin notifications are separate and can still occur. In Shopify admin, review Settings > Notifications > Staff notifications and disable the relevant staff notifications before importing Orders. Restore the intended live-store notification behavior after migration validation.

Creating or importing a Shopify customer profile is separate from sending an account invitation or other customer-account message. If the project depends on account invitations, password setup, marketing automation, an app workflow, or another customer message, verify that workflow separately before migration.

BigCommerce notifications

When Orders will be migrated to BigCommerce, open Settings > Order notifications and turn off all order notifications before the migration starts. Restore the intended notification settings when the store is ready for live operation.

Shift4Shop notifications

When Orders will be migrated to Shift4Shop, open Settings > Store Settings > Checkout and uncheck all settings inside the Order Notification section before the migration starts. With those notification settings disabled, customer emails are not sent during the documented migration workflow. Restore the intended notification settings when the store goes live.

Qualify trial and development target environments

A non-production Target Store can be used for migration work when the selected Next-Cart path can connect and the environment provides the structures needed for the planned scope. Keep the environment available long enough for migration and validation, and revalidate production-specific settings when the environment changes before launch.

Shopify trial and development stores

Next-Cart can migrate to Shopify trial and development stores when the selected migration path can connect and the environment exposes the structures required for the approved scope. Treat evidence from a non-production environment as environment-specific rather than proof of final production behavior.

For transaction testing in a Shopify development or client-transfer environment, use the test-order methods supported by that environment instead of assuming live transaction behavior. When the project moves to its production state, revalidate the connection, applications, notifications, payment and checkout behavior, and representative migrated data before launch.

BigCommerce trial and development stores

Next-Cart can migrate to both BigCommerce trial stores and BigCommerce development stores. Before using either environment, confirm that the selected Next-Cart path can connect, the required Product, Customer, Order, application, channel, and storefront structures are available, and the environment will remain accessible through the migration and validation window.

Other staging or non-production targets

For any other staging, sandbox, trial, or development Target Store, confirm that it can:

• accept the required records and target structures for the selected migration path;
• expose the administration features needed for validation;
• support the apps, extensions, languages, markets, channels, or storefront behavior required for the test;
• remain available long enough to complete the planned migration and validation work.

Do not generalize one platform’s sandbox or trial rules to another. Treat the result as evidence for the environment that was actually tested and recheck production-only settings and operational dependencies before launch.

Estimate migration duration from project evidence

There is no single migration duration that applies to every Source-to-Target path. Build the project estimate from the work that actually has to occur rather than from record count alone.

Separate the estimate into four windows:

1. Preparation and connection readiness: source exports or credentials, Target Store readiness, access, connection troubleshooting, and any Custom Migration clarification that must be resolved before processing.
2. Migration processing: record volume, Source and Target response time, API or connection constraints, media transfer, relationship processing, Add-ons, and approved Custom logic.
3. Validation and correction: representative record checks, Failed or Skipped investigation, platform-model differences, target configuration, and any rerun or corrective activity that follows the first result.
4. Final migration and launch preparation: the final additional-data scope, required Continue action and Additional Options, revalidation of changed data, and launch/sign-off tasks.

A Demo can provide useful evidence about connectivity, representative data structures, mapping behavior, media handling, and target representation, but its sample size and reduced feature scope make it unsafe to extrapolate a full-project duration by simple multiplication. Use Demo evidence together with source statistics, the purchased scope, Add-ons, approved Custom requirements, and the validation plan.

Re-estimate the window when the source volume grows materially, connection throttling or platform limits appear, media or relationship complexity is greater than expected, Custom scope changes, or validation uncovers a target-model issue. Treat every estimate as planning evidence, not a fixed processing or completion guarantee.

What to prepare by area

Area	Prepare this information	Why it matters
Migration access	Authorized user email, Order #, purchased migration, payment status	Identify the migration and confirm whether the user is the owner or has active Delegate Access.
Migration path and store identity	Source Platform, Target Platform, intended Source Store and Target Store	The purchased service applies to the selected path. Confirm which Store URL will become locked for the selected Source/Target setup when the successfully connected Connect Stores setup proceeds to the Configuration step; see Store URL Locking and Store Identity.
Access	Store admin access, API credentials, hosting access, source export access, or contact owner	Connection setup depends on what Next-Cart shows for the selected platforms.
Scope	Required data types, exclusions, filters, date ranges, and special records	Scope controls what must be migrated and validated.
Add-ons	Purchased Add-ons and where they apply	Add-ons affect supported migration behavior and configuration.
Custom Migration	Non-standard data, transformations, app/plugin data, and examples	Custom Migration requirements need clear examples and expected results.
Entity Points	Expected data volume and purchased Entity Points Plan	Capacity affects whether all eligible data can be migrated under the purchased plan.
Validation	Sample records, pass criteria, blocker definitions, launch timeline	Validation determines whether migration output is acceptable.
Security	Temporary access, cleanup owner, credential rotation plan	Access must be protected during and after migration work.

Expected result

After completing this checklist:

• the intended purchased migration is accessible to the authorized user who will perform the work;
• the migration path is confirmed;
• the source store and target store are accessible;
• the required setup owner is available;
• the target store is ready for validation;
• the data scope is clear enough to configure;
• non-standard requirements are documented;
• validation ownership and pass criteria are defined;
• security cleanup responsibilities are known.

Verification

Before moving to connection setup, verify these items:

Check	Pass condition
Migration access	The migration owner or an authorized delegated collaborator can open the purchased migration.
Service check	The migration path, Migration Service, Add-ons, and Entity Points Plan match your intended work.
Source check	The source store is accessible and contains the data you expect to migrate.
Target check	The target store is the correct environment and can be reviewed after migration.
Access-owner check	The right person can provide required credentials, files, or hosting access.
Scope check	Required data types and known exclusions are documented. For CSV, XLS, and XML, additional entity types are included only when they belong to the approved Custom scope.
Custom requirement check	Non-standard data or behavior is identified before configuration begins.
Validation check	Sample records and acceptance criteria are ready.
Security check	Temporary access cleanup is planned.

Failure handling

Issue	What to do
You cannot open the purchased migration	If you are the owner, recover your account access. If you are a collaborator, ask the owner to grant or verify Delegate Access.
The migration path is wrong	Do not configure migration work. Review the order or purchase the correct migration path.
Payment is incomplete	New Standard Migration or Managed Migration purchase: complete payment through Checkout. Approved Pending Payment order: resume payment from Orders, including Custom Migration after quote approval. Do not begin paid migration work until the order reaches Paid and any Custom Migration readiness requirement is satisfied.
The source store is unstable	Resolve source-store issues before connection setup. Avoid migration work during repairs or major updates.
The target store is not ready	Prepare the target store enough for validation before running full migration work.
Access owner is unavailable	Assign a replacement owner or delay setup until required access can be provided.
Scope is unclear	Use Define Migration Scope before configuring data types or Add-ons.
Non-standard requirements are discovered	Prepare Custom Migration requirements with examples and expected results.
Entity Points may be insufficient	Review your Entity Points Plan and upgrade if required.

Next Steps

If you need to	Go to
Coordinate project tasks, risks, evidence, redirects, and sign-off	Migration Project Toolkit
Define included data, exclusions, filters, and validation examples	Define Migration Scope
Prepare credentials or platform access	Prepare Source and Target Store Access
Document non-standard requirements	Prepare Custom Migration Requirements
Define pass and fail criteria	Define Acceptance Criteria
Start platform setup after preparation is complete	Connect Your Source and Target Platforms
Purchase a new migration or submit a Custom Migration quote request	Purchase a Migration