Moving email infrastructure sounds like a mundane IT task – ask anyone who has lived through a bad one, and they’ll tell you it’s anything but.
In 2018, when Spain’s Banco Sabadell completed its acquisition of Edinburgh-based TSB Bank, the integration seemed straightforward enough on paper, but then the migration happened. Millions of customers were locked out of their accounts for weeks, internal systems buckled, and the cleanup cost over £300 million ($397 million USD) – before counting the reputational damage.
Nobody planned for it to go that way. And that’s almost always how it goes. The TSB story gets cited in IT circles frequently, partly because of the scale but mostly because it’s so recognizable: the specific details change – smaller company, less users, less catastrophic outcomes – but underneath it all, the dynamic is the same.
Someone decided that moving critical data from one system to another was manageable and low risk – it wasn’t.
What actually has to move
Part of the problem is that “email migration” is a misleading term; it implies you’re moving messages, and you’re not.
What actually needs transfer is closer to a record of how an organization communicates and operates: email, yes but also calendar data, task lists, folder structures that employees spent years organizing, shared mailboxes, archived correspondence – which might have legal implications – audit logs, public folders.
Tools that handle this well – like Stellar Migrator for Exchange – allow you to filter by date range so you’re only moving what’s actually needed, and select exactly which folders transfer and which don’t. This kind of granular control matters more than it sounds – especially when you’re dealing with thousands of mailboxes.
Everything has to land in the right place, intact, or you spend weeks fielding complaints from people who can’t find anything.
Now, the most common scenario includes Microsoft environments: companies moving from on-premises Exchange to Microsoft 365, consolidating tenants after a merger, or upgrading between Exchange versions.
In this, Microsoft presents native tools for these transitions, but it’s not exactly friendly – or simple. IT teams without dedicated migration specialists frequently run into walls: the built-in tools lean heavily on scripting and manual configuration, which raises the skill floor considerably.
Even transitions that look straightforward on paper tend to generate friction once you’re actually in them. And friction in a migration doesn’t stay contained – it spreads.
Some third-party tools have addressed this directly. Stellar’s Migrator for Exchange tool, for instance, requires no command line working or scripting – steps are shown on-screen and it automatically matches accounts, which meaningfully lowers the barrier for IT teams that don’t have a migration specialist on staff.
The tooling gap – and what’s filling it
Over the past several years, a category of third-party migration tools has grown up around this problem – less scripting, more control, fewer surprises is what’s pitched. Whether they deliver on that depends on the tool and the context, but the better ones share a few characteristics worth noting.
Staged migration is probably one of the most important. Rather than moving everything at once in a high-stakes cutover, you migrate in batches: a department at a time, or a set number of mailboxes per day, which means problems surface before they’ve affected the entire firm.
Parallel processing is the other side of that coin. Stellar’s tool, for example, can handle up to 10 simultaneous mailboxes during a standard migration and up to 20 during a server upgrade. For larger teams, that flexibility is what makes a phased approach practical rather than painfully slow.
Direct server-to-server transfer matters too, particularly from a security standpoint. Stellar’s tool transfers data encrypted and directly between source and destination systems, with no third-party infrastructure in between.
This is not a minor detail – any intermediate staging environment is an exposure risk that probably isn’t in your threat model, and removing it from the equation is the right call regardless of which toll is being used.
The backup problem nobody talks about enough
The thing about migrations that doesn’t get enough attention is that a backup strategy is only as good as the last time it was actually tested. Although it sounds obvious, lots of organizations in practice discover mid-migration – or worse, mid-recovery – that their backups have gaps they didn’t know about.
Sunil Chandna, co-founder and CEO of India-based Stellar Information Technology, was direct about this while in conversation with Startup Beat: gaps usually only become visible when you’re already in trouble. By then, your options narrow considerably.
“Mailbox migration is no longer an isolated IT event. With hybrid and multi-tenant environments, it is a continuous business requirement. MSPs and enterprise IT teams need migration support – not added operational burden. We designed Stellar Migrator for Exchange to eliminate complexity at scale,” he stressed.
The discipline here isn’t complicated, but it requires actually doing it before you need it. Verify backups on both source and destination environments before migration starts; run a test restore; confirm that what you think is backed up actually is.
This isn’t about paranoia, but about having a real rollback option if something breaks halfway through. And, if the migration does go sideways and the backups aren’t sufficient, data recovery becomes the critical path.
At that point, professional recovery services may be the only option.
“If you do find yourself in that position, take the time to properly evaluate the situation before engaging a professional data recovery provider, because in many cases, you only get one opportunity to get it right,” Chandna said.
Where things fall apart
From talking to people who run these projects, the failure modes are pretty consistent: the scope problem comes up almost every time – someone inventories the primary mailboxes and misses the shared accounts, the distribution lists, the public folders and archive mailboxes sitting on a server that half the organization forgot existed.
This is where mailbox type coverage in your migration tool becomes a practical concern rather than a feature checklist item. Stellar, for instance, supports shared, arbitration, audit log, and monitoring mailbox types alongside the standard ones – the kind of edge cases that tend to surface only after someone realizes they’re missing.
Rollback planning – or its absence – is the other big one. Migrations get treated as one-way operations up until something goes wrong, at which point there’s no clean path back. Building a rollback plan feels like pessimism when you’re in planning mode; it feels like foresight afterward.
Testing the destination environment before cutover is another step that gets skipped more than it should. Configuration issues in the new environment only surface after users lose access to the old one – which is exactly when you don’t want to be diagnosing them.
And timing. Running a migration during business hours, or without giving users meaningful notice, generates a support queue that has nothing to do with technical failure – just people who didn’t know what was happening and suddenly can’t find their email.
Where the paradigm leaves us
The best tools today – which are considerably better than in years back – are more capable than what was available even five years ago.
The gap between a successful migration and a failed one has shifted away from tooling and towards the less glamorous stuff: planning discipline, testing rigor, communication with end users, and not treating complex data operating as a checkbox.
TSB is an extreme case, clearly. But the pattern it represents – confident underestimation of a migration’s complexity – shows up at every scale. The costs are usually smaller. Yet, they’re rarely zero.
Disclosure: This article mentions clients of an Espacio portfolio company.
