A few weeks ago I wrote about how much history to migrate after an acquisition. There’s a second reason to migrate less: every trial migration makes another copy of it.

In January 2024, Microsoft disclosed that a Russian state-sponsored group had accessed corporate email, including senior leadership accounts. The way in was not a production system. It was a legacy, non-production test account without multifactor authentication.

That wasn’t a data migration, but the lesson carries over directly. A migration is not one data move. It’s a series of trial runs, and each one copies real customer, employee and financial records into staging databases and test environments. Those environments rarely get the same protection as production, and old copies tend to outlive the project.

You can’t validate a migration on fake data, because the problems hide in the real records. You can treat migration environments like production:

  • Apply production-level access controls and multifactor authentication.
  • Mask fields the validation doesn’t need, such as Social Security and bank account numbers.
  • Track who has access to which copy.
  • Schedule deletion of old trial copies.
  • Put all of it in the integration budget and the security review.

Migrating less history also means fewer sensitive copies to protect.

Does your integration plan name an owner for the security of trial-migration environments?

For more on de-risking post-acquisition data migrations, download our white paper.

Sources: Microsoft Security Response Center, “Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard,” January 19, 2024; Microsoft Security blog, “Midnight Blizzard: Guidance for responders on nation-state attack,” January 25, 2024.

Originally posted on LinkedIn.