How to keep your data safe during a cloud migration

Short answer: A cloud migration is the period when your data is most exposed – in transit between two environments, sitting in temporary staging locations, accessible to migration tooling with elevated credentials, and replicated across systems with permissions that have not been hardened yet. To keep data safe, encrypt every transfer end-to-end, use short-lived migration credentials with the smallest possible scope, freeze permission changes during cutover, run a parallel environment with read-only access on the source, and audit the destination tenant before you decommission anything.

Most SMBs treat security as a post-migration cleanup task. By then it is too late – if a credential leaked during the migration, the attacker is already in. This article covers what actually goes wrong during cloud migrations, in the order it tends to fail, and how to plan around each risk before cutover weekend.

Cloud migration security risks at a glance

Risk area	What goes wrong	When it bites
Data in transit	Unencrypted transfers, weak TLS, misconfigured endpoints	During migration windows
Migration credentials	Long-lived service accounts with global admin, stored in scripts	During and after migration
Permission drift	Source ACLs replicated as-is, broken inheritance, oversharing	Days after cutover
Parallel environments	Two writable copies, conflicting changes, stale data leaks	During cutover weekend
Incomplete decommission	Old systems left online, DNS still resolves, data not destroyed	Weeks to months later
Audit gaps	No logging on the destination during migration, evidence loss	When something goes wrong

The pattern is consistent: the riskiest moments are the cutover window itself, and the 30 to 60 days after, when permissions and accounts are still being reconciled. Treat both as security-critical, not just IT operations.

Why migration is a high-risk period

A cloud migration creates four conditions that attackers exploit.

More credentials in circulation. Migration tools need access to source mailboxes, file shares, databases, and the destination tenant. SMBs often create one global-admin account, give it to a vendor, and forget to remove it after cutover. That account is a master key, and it lives in scripts, vendor laptops, and password managers for years.

More data in motion. Migration is essentially “copy everything from A to B.” Some of that data is sensitive (client records, financial data, regulated content). Misconfigure the transfer, and that data is either intercepted in transit or staged on a third-party migration appliance that you do not control.

Permissions are unreviewed. Migration tools replicate source permissions as-is. If your old file server had broken inheritance, group sprawl, and a folder shared with “Everyone” since 2014, that all moves with you – now exposed in a tenant where external sharing is one click away.

Logging is incomplete. During the cutover window, you are running two systems in parallel. Audit logs are split, monitoring may not be configured on the destination yet, and some changes are made directly through migration tools that bypass normal admin paths. If something goes wrong, you may not have evidence.

These risks compound. A leaked migration credential plus replicated oversharing plus no destination logging is a textbook breach scenario – and it has happened to plenty of SMBs that thought a migration was an IT project, not a security project.

Encryption: in transit and at rest

The first thing to lock down is the transport.

Data in transit

Every connection involved in the migration should use TLS 1.2 or 1.3 – source to migration tool, migration tool to destination, admin consoles, and any service-to-service traffic. This sounds obvious, but real migrations fail it routinely:

• Legacy SMB file shares transfer in cleartext over older SMB versions if the migration runs on a flat network. Force SMB 3.x with encryption, or stage data through a host that requires it.
• Email migration tools sometimes use IMAP without TLS, or connect to Exchange over insecure RPC. Verify the protocol your migration tool uses, and require TLS at the source.
• Database backup files copied to a SaaS migration tool may transit in cleartext if the upload endpoint is HTTP rather than HTTPS. Check every URL the tool uses.
• VPN-only assumptions. “It is going over the VPN” is not encryption. Plenty of VPNs negotiate weak ciphers, and some site-to-site VPNs do not encrypt at all if misconfigured.

For Microsoft 365 migrations, the Microsoft tooling enforces TLS by default. For third-party tools, ask the vendor: what TLS version, what cipher suite, and how do we verify the connection. If the vendor cannot answer, that is your answer.

Data at rest

Once data lands in the destination, it should be encrypted at rest using keys you can audit. For most SMB cloud migrations, this means:

• Microsoft 365 / SharePoint / OneDrive: encryption at rest is on by default, using Microsoft-managed keys. Customer-managed keys (Customer Key) are available for Microsoft 365 E5 / Premium tiers if you need them for compliance.
• Azure Storage: encryption at rest is on by default. For sensitive data, consider customer-managed keys via Azure Key Vault.
• AWS S3: server-side encryption is on by default since 2023. Verify the encryption mode (SSE-S3, SSE-KMS, or SSE-C) is appropriate.
• On-prem to cloud staging: if the migration uses a staging appliance (NAS, Azure Data Box, AWS Snowball), confirm the device is encrypted and that the encryption keys are not stored on the device itself.

The mistake here is assuming “the cloud is encrypted” without checking which encryption, with whose keys, and how rotation works. For regulated industries, you will need to document this in writing.

What about temporary copies

Migration tools often create staging copies – intermediate file shares, mailbox staging databases, transient blob containers. These are easy to forget. Ask the vendor:

• Where does the data live during migration?
• Is that staging location encrypted?
• When is staging data deleted?
• Can you provide a deletion certificate?

If the migration tool stages data on the vendor’s own infrastructure, you have effectively shared your data with that vendor for the migration window. That should be in your contract, with a clear deletion timeline.

Migration credentials: short-lived, smallest scope

The single biggest credential mistake in SMB migrations is creating a global-admin service account, sharing it with the migration vendor, and never rotating or deleting it.

The right pattern:

Use dedicated migration accounts. Do not reuse existing admin accounts. Create accounts specifically for migration work, named clearly (e.g., [email protected]), and disable or delete them when migration is complete.

Smallest scope possible. A file server migration does not need global admin in Microsoft 365 – it needs SharePoint admin and a service account with read access on the source. An email migration needs Exchange admin, not Entra ID global admin. Audit the actual permissions the migration tool requires, and grant only those.

Time-bound the credentials. Set a calendar reminder to disable the account on a specific date. Better: configure conditional access policies that limit when and where the migration account can sign in (specific IP ranges during the migration window only). For Microsoft 365 environments, see how to configure conditional access in Microsoft 365 for the policy patterns that work.

MFA where possible. Many migration tools support MFA-enabled service accounts via app passwords or modern auth. If yours does not, isolate the account behind conditional access (location-restricted, device-restricted) instead.

Rotate when done. Within 24 hours of cutover, disable the migration account. Within 30 days, delete it. Document the rotation in your audit trail.

Vendor laptops are credentials too. If a migration vendor stored your credentials on their laptop, those credentials are only as secure as their laptop. Ask: is the laptop encrypted? MFA-enabled? Patched? Wiped after the engagement? You can require this in writing.

For background on why over-permissioned accounts are such a frequent breach root cause, zero trust security: what it means for small business covers the principle of least privilege in the context of cloud-era IT.

Permissions: do not replicate the mess

The most common file server migration security failure is “we copied the permissions exactly as they were.” That sounds correct – users get the same access they had before – but it ignores that on-prem permissions were often:

• Inherited from group memberships nobody remembers maintaining
• Granted to “Everyone” or “Domain Users” because that was easier than building proper groups
• Broken at unpredictable folder levels because someone tried to fix one share five years ago
• Unaudited – nobody has ever reviewed who has access to what

When you replicate that into SharePoint or OneDrive, you inherit every problem. And SharePoint is far easier to overshare from than a file server (one click and a folder is shared externally).

The right approach:

1. Audit permissions before migration. Before you run the tool, generate a permissions report on the source. Look for “Everyone,” “Authenticated Users,” and any share with permission lists longer than 20 entries. Those are red flags worth fixing before migration, not after.
2. Build proper groups. Migration is a rare opportunity to clean up. Create role-based groups (Finance, HR, Engineering) and assign permissions to those groups – not to individual users.
3. Block external sharing during migration. Disable external sharing in the destination tenant (or tenant-wide) until migration is complete and permissions are audited. Re-enable it deliberately, with sharing policies that prevent accidents.
4. Audit after migration. Within the first week after cutover, run a permissions report on the destination. Look for files shared externally, anonymous links, and permissions that should not have come across. The Microsoft 365 security audit checklist for SMBs walks through what to check, in what order.
5. Monitor for the first 60 days. Set up alerts for unusual sharing activity, mass downloads, and external access creation. The permission drift that causes the breach usually shows up in the first two months as people figure out the new system.

This step is where in-house IT often runs out of bandwidth. The migration tool finishes, cutover succeeds, the team moves on – and the permission audit never happens. That is exactly the gap a managed provider should close.

Parallel environments: cutover without leaks

Most cloud migrations run a parallel period – the source is still live, the destination is being populated, and at some point you cut traffic over. This window is risky for two reasons: data can leak across both copies, and authoritative state becomes ambiguous.

Make the source read-only as early as possible. The longer you have two writable copies, the more reconciliation problems you create – and the more chances for sensitive data to be in two places at once.

Define a single source of truth at every moment. During pre-cutover, the source is authoritative. During cutover, neither system accepts writes (briefly). After cutover, the destination is authoritative and the source is read-only. Any time both systems accept writes, you are creating a data integrity and security problem.

Lock the source on cutover. When you flip the cutover switch, immediately disable writes on the source. For email, this means putting source mailboxes into a state that rejects new mail (or forwards it). For file servers, set the share to read-only. For databases, take the source offline.

Plan for the rollback case. If cutover fails, you may need to send users back to the source. That means the source has to remain technically available for some defined window, even though it is read-only. Decide in advance: how long, who decides to roll back, and what happens to data created on the destination during the failed cutover. The cloud migration checklist for small business walks through the rollback decision sequence in detail.

Network-isolate the parallel copies. During the parallel period, if the source and destination should not be talking to each other (apart from the migration tool), enforce it. Firewall rules, separate VPCs, separate identity providers – whatever the architecture requires. The default of “they are on the same network so they can see each other” is how lateral movement happens if one side gets compromised.

DNS, MX, and identity cutover

The cutover itself usually means changing DNS records, MX records, or identity federation. Each of these has a security dimension.

MX records (email): Until MX cuts over, mail still flows to the source. Some attackers watch for businesses mid-migration and send phishing during the window when spam filtering is weakest (because the destination’s filtering rules are not fully tuned yet). Make sure SPF, DKIM, and DMARC are configured on the destination before MX cuts over – not after.

Public DNS records: A cutover often means pointing app records or website records to new infrastructure. Set short TTLs (300 seconds) at least 48 hours before cutover, so when you flip the records, the old infrastructure goes dark fast. After cutover stabilizes, return TTLs to normal.

Identity cutover: If you are moving from on-prem AD to Entra ID (or hybrid), the cutover involves password sync, federation changes, and possibly a forest trust. Each of these is a high-value target for an attacker who has been waiting for a chance. Use break-glass accounts (cloud-only, MFA-protected, monitored) so you can recover if federation breaks. Stage the cutover – identity first, services second.

MFA enrollment timing: A common error is migrating users into a destination tenant where MFA has not been enforced yet, so accounts are protected by password only for the first few days. Enforce MFA on the destination before any user mailbox is migrated. New accounts should never go live in an MFA-disabled state.

The first 48 hours after cutover are the highest-risk window for credential-stuffing attacks against the new tenant. Watch for unusual sign-in activity from new IP ranges and locations.

Decommissioning the old environment safely

Decommission is where SMBs lose data and create breach risk. The old server sits in a closet, still on the network, still resolving DNS, still authenticating accounts – but nobody is patching it because “we migrated off it.”

Standard decommission timeline:

Phase	Timing	What happens
Read-only standby	Cutover + 0 to 30 days	Old system stays online, read-only, for rollback or data lookup
Network isolation	Cutover + 30 to 60 days	Old system removed from production network, kept on isolated segment
Powered off	Cutover + 60 to 90 days	Old system shut down, kept for one final data check
Data destruction	Cutover + 90+ days	Drives wiped to standard, hardware disposed or recycled

Concrete decommission steps:

1. Confirm data was actually migrated. Run a final reconciliation – file counts, mailbox counts, database row counts – between source and destination. Fix any gaps before you decommission anything.
2. Revoke service account access. The migration accounts you created should be disabled. Any application that authenticated against the old system should be reconfigured against the new one.
3. Remove DNS entries. Internal and external DNS records that pointed to the old system should be deleted, not just left to time out. Stale DNS is a frequent root cause of “we found a forgotten server still serving traffic” incidents.
4. Remove from monitoring and patching. If the old system is still in your RMM, it is going to keep producing alerts and consuming licenses. If it is removed but still online, it is going to stop receiving security patches. Pick one path – keep it monitored and patched, or take it fully offline.
5. Secure data destruction. Drives that held customer data, financial records, or regulated content should be wiped to a recognized standard – DoD 5220.22-M for general data, NIST 800-88 for regulated. Get a destruction certificate from whoever does it.
6. Document the decommission. Date, system, who decommissioned it, what data was on it, how it was destroyed. This document matters for audits, insurance, and the inevitable “what happened to that server” question two years later.

For regulated industries, decommission is not optional cleanup – it is part of compliance. HIPAA cybersecurity requirements covers media disposal requirements specifically; CMMC and PCI have their own. For the full decommission playbook – phased timeline, license and contract cleanup, hardware disposition options, and the documentation that satisfies an auditor – see how to decommission old servers after a cloud migration.

Backup during migration: do not skip this

During a cloud migration, your backup story gets messier than usual:

• The source is in flux (data is leaving).
• The destination is in flux (data is arriving).
• The migration tool may be your only “backup” if the source has been decommissioned and the destination has not been backed up yet.

The right pattern:

Backup before you start. A full, verified backup of the source – taken before migration begins, stored offline or immutable – is your insurance against migration corruption. Verify the restore actually works on a test system. How to test your business backup covers what verification looks like.

Configure destination backup before cutover. Microsoft 365 does not back up your data the way most SMBs assume – the Microsoft 365 backup gap is a separate problem from migration. Have your independent M365 backup configured and running before you cut over user mailboxes.

Keep source backups for the full retention period. Even after decommission, keep the pre-migration backup of the source for whatever your data retention requires – typically 7 years for financial data, longer for regulated industries. Migration is not a reason to shorten retention.

Ransomware-aware backup architecture. A migration is exactly the kind of disruption ransomware actors look for. Make sure backup systems are immutable, segmented, and not accessible from the migration accounts. Ransomware and backup: why your backup might not save you explains the architecture that survives an attack on backups themselves.

Post-migration security audit

The day after cutover is not the end – it is the start of the highest-risk period. Before you mark migration “complete,” run a security audit on the destination:

Identity and access:

• Who has admin rights in the destination tenant? Is that the right list, with MFA enforced, with conditional access in place?
• Are migration service accounts disabled?
• Are emergency/break-glass accounts secured and monitored?

Data exposure:

• Run a sharing report on SharePoint/OneDrive. Anything shared externally? Anonymous links?
• Files with broken inheritance or permissions inconsistent with the new group structure?

Email security:

• SPF, DKIM, DMARC records valid and aligned?
• Connectors not allowing external mail bypass?
• Forwarding rules audited (a common attacker persistence trick)?

Logging and monitoring:

• Audit logging enabled? Log retention set to your required period?
• Alerts configured for unusual sign-ins, mass downloads, external sharing creation?
• SIEM or MDR ingesting logs from the destination tenant?

Compliance documentation:

• Data flow diagram updated?
• Records-of-processing or data inventory updated?
• Encryption documentation updated?

This audit is what closes the migration. Skip it, and you have moved to a new platform with the security of your old one – but with more attack surface.

Common mistakes that cause data loss or breaches

1. Treating migration as IT-only. No security review, no audit, no signoff. Migration succeeds technically and creates a security incident weeks later.
2. Sharing global admin with the vendor. And never rotating it after cutover. The credential persists for years.
3. Skipping the pre-migration permissions audit. “We will clean up after.” After never comes.
4. Assuming the cloud is secure by default. It is secure to a level. Misconfigured tenants are not. Default sharing settings, default MFA settings, and default conditional access can all be wrong for your business.
5. Cutting MX before SPF/DKIM/DMARC are valid on the destination. Mail flows, but with no authentication. Spoofing risk skyrockets for the first few days.
6. Leaving the old system online. “Just in case.” Six months later it is unpatched, forgotten, and exploitable.
7. Not testing the backup before cutover. And then needing it during cutover. Restore fails. There is no plan B.
8. No logging on the destination during migration. When something goes wrong, there is no audit trail to show what happened.
9. Forgetting compliance documentation. Regulated industries need data flow diagrams, encryption documentation, and records-of-processing updated before the auditor shows up.
10. Declaring “done” before the post-migration audit. Migration is not done at cutover. It is done after the security audit confirms the new environment is hardened.

Special considerations by data type

Customer PII: Encrypt in transit, encrypt at rest, document retention, and audit access logs for the first 60 days post-migration. Know which data subjects to notify if anything goes wrong.

Financial data: Maintain audit trails through the migration period – both source and destination logs need to be preserved. Some regulators (FINRA, SEC) require a continuous audit trail.

Healthcare data (PHI): HIPAA requires Business Associate Agreements with anyone handling PHI during migration – including the migration vendor and the destination cloud provider. Verify the BAA is in place before any PHI moves.

CUI / defense data: CMMC and DFARS require specific encryption levels (FIPS 140-2 validated), specific cloud regions (US sovereignty), and specific destruction standards. Migration is not a workaround for these requirements.

Legal records: Privilege does not transit cleanly through every migration tool. Verify chain of custody and that the migration does not break privilege protections.

If you operate in any of these categories, the security plan for migration is part of your compliance posture – not separate from it.

How long does the security work take

Migration scope	Security work hours	What that covers
Email-only (under 25 users)	8 to 16 hours	Pre-migration audit, MFA enforcement, post-cutover audit
Email + file storage (25 to 100 users)	24 to 48 hours	Plus permissions audit, sharing policy, post-migration sharing review
Full M365 + servers (100 to 250 users)	60 to 120 hours	Plus identity hardening, conditional access design, full destination audit
Multi-server with regulated data	120+ hours	Plus compliance documentation, BAA review, encryption documentation, audit-grade evidence

These are the hours dedicated to security work specifically – separate from the migration execution hours. Skip them and you have moved data without protecting it.

How Sequentur can help

If you are planning a cloud migration and want help locking down the security side – or just a second pair of eyes on your plan before cutover – schedule a call.