Data security during Business Central cloud migration

When Business Central moves from your own server to BC online, Microsoft takes over a large part of the security work: servers, patches, database encryption and backup. But not all of it. Who may see payroll accounts, who can change bank details on a vendor, and how data gets safely from the old system to the new one: that is still your responsibility.

Here is what we go through with customers before we move them from C5 (a Danish accounting system), NAV or on-premises BC.

Understanding the security landscape

A cloud migration has five security surfaces. Microsoft handles the first two for the most part. The last three are yours:

• Data in transit: Microsoft's migration tool moves data encrypted. With file-based migration, for example from C5, the risk is the export file on someone's desktop
• Stored data: BC online encrypts the database and takes backups. You do not need to set that up yourselves
• Access control: Users and permissions are not carried over in the cloud migration. That is a task, and a good occasion to clean up
• Compliance: GDPR, the Danish bookkeeping law (bogføringsloven) and your auditor's requirements still apply, wherever the server stands
• The transition period: Two systems run in parallel, and data sits in test environments and export files

Key security measures

1. Map before you move

Start by knowing what you have. In a NAV system that has run for 15 years, there is typically more in there than anyone remembers:

• Which tables contain personal data: customers, contacts, employees, and perhaps CPR numbers (Danish personal ID numbers) in custom fields
• Who has SUPER today, and why
• Integrations with stored usernames and passwords: FTP, web services, NAS jobs
• Custom tables and fields in the customisations that need to come along, or be left behind on purpose

A thorough security assessment before the migration reduces the risk of unexpected security problems by up to 70% during the migration process.

2. Secure data transfer

The move itself is rarely the problem if you use Microsoft's tools. It is everything around it:

• From on-premises BC: use the Cloud Migration tool. Data goes encrypted via a self-hosted integration runtime, not via files
• From C5 and older NAV: keep export files in a controlled place, and delete them after go-live
• Do not share a sandbox with production data with external parties without anonymising personal data
• Reconcile after the transfer: balance, open entries and inventory value at the cut-off date

3. Access control from the ground up

BC online signs in via Microsoft Entra ID. That gives you tools you did not have on your own server:

• Require MFA for all users, including the bookkeeper who only signs in from the office
• Assign permissions via security groups in Entra ID instead of user by user
• Build your own permission sets from Microsoft's standard sets instead of granting SUPER
• Separate who creates vendors and bank accounts from who approves payments
• Give your partner access via GDAP with a time limit. That applies to us too

4. Encryption and data that leaves BC

In BC online the database is encrypted, and all traffic goes over TLS. That is Microsoft's responsibility. Your part is about the data that leaves the system:

• Integrations sign in with OAuth via an app registration in Entra ID, not with a user's password
• Secrets in your own apps belong in Isolated Storage or Azure Key Vault, not in a setup table
• Payments go through a direct bank integration such as Continia Banking rather than payment files in a shared folder
• Excel extracts with personal data are not sent around by email

5. Monitoring after go-live

Security does not stop at go-live:

• Switch on the change log for the fields that matter: bank accounts on vendors, payment terms, credit limit
• Send telemetry to Application Insights, so failed integrations and unusual activity become visible
• Keep an eye on the sign-in log in Entra ID
• Review users and permissions every quarter. Employees who have left stay on more often than you think

Handling compliance requirements

Microsoft has the certifications. It is still you who must use the system so that it meets the requirements:

• GDPR: Know your personal data in BC, classify the fields, and use retention policies to delete what you are not allowed to keep
• Bookkeeping law (bogføringsloven): Accounting records must be kept for five years. Decide what happens to the history from the old system
• ISO 27001 and industry requirements: If you are certified yourselves, BC permissions and supplier agreements must fit into your ISMS

Microsoft provides the secure foundation. The set-up is yours, or your partner's.

Risk management during migration

Most of what goes wrong goes wrong in the transition:

• Make a short risk list: What do we do if the bank integration does not work on Monday morning?
• Test in a sandbox with the users' real permissions, not only as SUPER, otherwise the users find the errors on day one
• Have a rollback plan: When do we decide to continue in the old system?
• Close the old system for posting, but keep read access until the first VAT settlement is reconciled

Security after migration: best practice

Once you are in operation, it is about fixed routines:

• Quarterly review of users, licences and permission sets
• Microsoft updates BC online, but your own apps and third-party apps have to keep up. Test in a sandbox before the major releases in April and October
• Teach users to recognise phishing and fake changes of bank details from "vendors"
• A plan for incidents: Who do you call, and who can close a compromised account
• Microsoft can restore the environment to an earlier point in time. If your policy requires more, make your own exports of critical data

Conclusion

A move to BC online makes most companies more secure, not less: no server in the basement, no forgotten patches and MFA on every sign-in. But the gain only comes if permissions, integrations and the transition itself are handled properly.

It is a shared responsibility. Microsoft secures the platform. Who may do what, and how data gets in and out of the system, is yours. We are happy to help with that part.