Prepare and plan for cloud migration from Business Central on-premises

This article provides recommendations to help you define your cloud migration strategy and get environments and users ready for cloud migration.

Assess your current state

Before you start planning what data to migrate, assess your current on-premises environment to understand the scope and effort required. The following checklist outlines the key areas to review:

• Current version and cumulative update level: Identify your current Dynamics NAV or Business Central on-premises version. This information determines the upgrade path you must follow.
• Database size, growth rate, and number of companies: Measure the current database size and identify how many companies you need to migrate. Large databases or many companies require more planning around batches and timing.
• Customization inventory: Catalog all modified objects, ISV add-ons, and integrations. Customizations typically represent the biggest technical risk and effort in a migration.
• Performance baseline and largest tables: Identify the largest transactional and log tables. These tables affect migration duration and may be candidates for archiving or cleanup.
• Compliance and data residency requirements: Determine whether data residency, industry compliance, or security requirements affect your migration approach or target environment region.
• Business validation criteria and sign-off owners: Define who validates the migrated result and what success criteria must be met before cutover.

Determine what data to migrate

The data that's migrated is determined on two levels: per-company and per-extension.

Company data

When a company is migrated, data in company-specific tables of base application is migrated, along with company-specific data belonging to other extensions (for information, see the next section).

You can choose to migrate data for all companies or only specific companies. It's recommended to determine which companies to migrate upfront to save time and resources. Keep in mind that the more companies you replicate in a single operation, the longer the migration takes. The cloud migration capabilities are optimized to migrate data in batches of up to 10 companies. If you have more than 250 companies, it's recommended to plan to run the migration in smaller batches. For more information, see Optimizing cloud migration performance.

You can migrate all the data that you want to take with you to the cloud, but be aware of the storage capacity of your online tenant. If you need more storage than the default 80 GB, you can buy another environment or extra storage capacity. Storage capacity is determined as 80 GB + allowances per licensed Essential/Premium user + any storage capacity licenses. Learn more in Managing Capacity.

Extension data

In general, on-premises data in table objects and table extension objects belonging to an extension is only migrated if the following conditions are met:

• The extension is installed on online environment.
• The extension's ReplicateData property is set to true.

Because true is the default setting, most extensions that are installed on the Business Central online environment will have table data migrated.

In certain circumstances, you might not want to migrate all data. Here are a couple examples:

• The extension is installed in the Business Central online environment but not in the Business Central on-premises solution

  In this case, Business Central attempts to migrate the data but shows a warning. Because the extension isn't installed on-premises, any table related to that extension table isn't migrated, and warning notifications appear in the cloud migration status page.

  If you own the extension, we recommend you set the ReplicateData property to No on the extension tables. If you don't, and if you want data to migrate, install the extension in both Business Central online and your on-premises solution. If you don't want data to migrate, uninstall the extension from the Business Central online environment.

• The extension references a base table

  This condition can cause your base table to appear empty when you view data in your Business Central online tenant. In such cases, uninstall the extension from your Business Central online tenant and then run the cloud migration process again.

  Business Central inserts the default values and records into the table extensions automatically. If there are any problems, you can use the Repair Companion Table Records action on the Cloud Migration Management page to insert the missing table extension record

For more information, see FAQ about migrating to Business Central online from on-premises solutions and Troubleshooting cloud migration.

Estimate the data size in your Business Central online tenant

In the online version of Business Central, data is compressed using the SQL Server data compression feature. This condition means that the data size in your on-premises database might not match the data size when migrated to the Business Central service. For more information on estimating the compressed size of your data, see Estimating the data size in your Business Central online tenant.

Prepare your data for migration

Use the period before migration to reduce technical debt and potential issues in the database:

• Archive obsolete history and shrink oversized transaction or log tables where appropriate.
• Validate that any schema changes in your database are intentional and expected.
• Confirm that the SQL Server version and database compatibility level meet the requirements (SQL Server 2016 or later, compatibility level 130 or higher).
• If you plan a multi-company migration, design batches early so that timing and validation can be repeated consistently across dry runs and the final cutover.
• Consider reducing the amount of data so that it's less than 30 GB per migration run. If your Business Central online storage exceeds 80 GB, some administrative tasks are disabled.

Plan your environment strategy

When you set up cloud migration, the migration process replicates data into the target online environment. Don't set up cloud migration for a production environment that's already in use for business, because replication can overwrite data in the target environment.

Instead, use a sandbox environment for dry runs and validation. This approach helps you identify issues and measure timing without risking production data. Only use a production environment as the target for the final cutover when you're ready to go live.

Plan advanced migration approach

It's important to have a solid migration strategy in place to ensure a smooth transition. Most migrations can run from the on-premises production database with minimal downtime for end users. However, for especially large migrations, it might be better to run migration from a backup of the on-premises database deployed as Azure SQL Database. Doing migrations this way improves migration speeds and minimizes performance loss and downtime on the on-premises production database.

1. Enable change tracking on the on-premises production database for the expected number of days between the first backup for replication and the next time you'll back up and replicate. A minimum of three days is enforced. The number of days for which change tracking is enabled can't be changed later without resetting change tracking altogether.

   Note

   • Long retention periods for change tracking data might cause database resource starvation when high volumes of data are changed on the database, which may lead to reduced database performance and/or loss of the change tracking data. Pick a change tracking period that strikes a balance between migration strategy needs and available resources on the on-premises database.
   • Don't enable change tracking if you'll be running data upgrade on-premises, because it won't work.

2. Create a full backup of the on-premises production database. Differential or partial backups aren't supported as they don't include Change Tracking data required for replication runs.

3. Optionally, deploy the backup database to an Azure SQL Database for improved performance. See Optimizing Cloud Migration Performance.

4. Complete the usual preparation steps on the backup on-premises database and address any issues that arise. Start the first replication run and address any issues that arise.

5. Within the change tacking period set up on the on-premises production database in step 1, overwrite the backup database with a new full backup to replicate data that is new or modified since the backup created in step 2.

   Note

   Rather than overwriting the backup, the old backup database can also be deleted. If creating a new backup rather than overwriting an existing backup, ensure the new backup database has the same name as the previous one. If the database name changes, run the Cloud Migration setup in the cloud environment again to point to the new database; the tooling will still attempt to use Change Tracking data if available to avoid replicating all data in the source database.

6. Repeat steps 2-5 as needed until you reach a state that is suitable for the final migration run.

7. Stop the usage of the on-premises environment ahead of the final backup of the on-premises production database. Run one final replication from the backup database to replicate the last data before running data upgrade.

   Important

   Before running data upgrade, ensure that data from all companies has been replicated to the online database. Once you run data upgrade successfully, you can’t run data replication again from an earlier version, because you risk corrupting data in the online database by mixing non-upgraded records with upgraded records.

8. Run Data Upgrade on the cloud environment.

   This step isn't required if you're on-premises version is the same as Business Central online (that is, both are the most current versions).

9. Complete the migration and go live on the cloud environment.

Keep in mind that the migration process can be complex, and issues might arise that require more troubleshooting. It's important to stay flexible and be prepared to adjust your migration strategy as needed to address any problems that arise.

Create a governance plan

Create a migration runbook that documents the owners, dependencies, expected durations, decision gates, change freeze timing, and rollback options for each phase of the migration. Update the runbook after each dry run with newly discovered issues and their mitigations. A well-maintained runbook helps ensure that everyone involved understands their responsibilities and that the migration proceeds predictably.

Runbook checklist

A comprehensive migration runbook should include:

Dry run cadence

Plan at least two dry runs before the production cutover:

1. First dry run: Identify technical issues, measure timing, and validate the migration process in a sandbox environment.
2. Second dry run: Confirm fixes, refine timing estimates, and conduct business validation with key users.
3. Final cutover: Execute the production migration using the validated runbook.

Schedule

• Plan the switch to use Business Central online for production carefully to not start until migration is complete

  Don't set up cloud migration for a production environment that's already in use for business. You risk that the migration process overwrites data that's needed to run the business. Even if your migration targets a different company in that environment, you risk that the upgrade overwrites data that's shared across companies in the target environment.

• Schedule the migration to not conflict with an update of Business Central online

  Once you set up cloud migration for an environment, the environment can't be updated. If you want to update the environment, you must disable cloud migration. If an update is available, and you haven't started migration, then update target environment first, then migrate. If you have already started the cloud migration process, we recommend that you continue migrating all companies, complete cloud migration, and then update to the next major/minor. By separating update from cloud migration, we remove the risk of potentially corrupting data if the update touches tables with records in both migrated and non-migrated companies.

Next steps

• Check prerequisites
• Optimizing cloud migration performance
• Run data migration setup