Tenant to tenant migration after acquisition: the 60 days a Bengaluru fintech merged two M365 tenants
Last updated: 29 June 2026
A tenant to tenant migration after acquisition is rarely about the tool. In 2026 a CFO asked me which migration tool was cheapest. That is not the question. The question is what a broken cutover costs a lending business that runs on email and shared files, and how many days of “we cannot see each other’s calendars yet” the board will tolerate after they announced the deal. Cheapest tool, most expensive outcome. We have seen that movie.
This is the story of one merge. A Bengaluru fintech, roughly 400 staff, bought a 90-person analytics shop in Chennai. Two separate Microsoft 365 tenants, two domains, two sets of habits. The brief from the top was simple and slightly unfair: one company by the next board meeting. Sixty working days. A tenant to tenant migration after acquisition was the only path that fit.
The acquisition closed. The two tenants did not.
Day one after signing, both companies still logged into their own worlds. Vikram, the acquirer’s IT head, called me on a Tuesday. His problem was not technical yet. It was human. His CEO had already told 490 people they were “one team now,” and those people opened Outlook and saw exactly nobody from the other side.
Matlab, the announcement moved faster than the plumbing. That is normal. Leadership signs the deal, then the IT head inherits the gap between the press release and reality. Vikram had inherited a big one. The Chennai team’s mailboxes, their five years of SharePoint files, six Teams full of project history, and a finance shared mailbox that nobody was allowed to lose for audit reasons.
His first instinct was to ask Microsoft to “just merge them.” Tenants do not merge. You move objects from one into the other, then retire the empty one. Bas, that reframe alone changed how Vikram talked to his CEO about the timeline.
What actually moves in a tenant to tenant migration after acquisition
We sat down and listed it, because the size of the list is what sets the plan. People underestimate this part every time.
490 mailboxes, including 30 shared and resource mailboxes. About 2.1 TB across OneDrive accounts. Eleven SharePoint sites, two of them large document libraries the lending team lived in. Six Teams, with channels, files, and chat history people genuinely referenced. And underneath all of it, identity: every user account, the groups, the licences, the conditional access rules that decide who gets in from where.
That last layer is where merges quietly go wrong. You can move a mailbox and still lock a user out because their sign-in, their multi-factor setup, and their group membership did not travel with it. We pair this kind of move with an identity plan early, the same way we did in a Mumbai NBFC’s identity shortlist. Get the directory wrong and the mailbox move is the easy part you finish on time while users still cannot log in.
There is also the data nobody volunteers to think about. This is a lending business. Customer financial records sit in those mailboxes and sites. Moving them between tenants is a controlled transfer of personal data, not a file copy. Achha, so now compliance is in the room too.
200+ Indian businesses served. Response within 8 hours. No card, no contract, no sales call.
The argument we had about doing it by hand
Vikram’s senior admin wanted to do it manually. Export PST files, re-import, copy SharePoint with a script, rebuild Teams from scratch. No licence cost, he said. He was not wrong about the licence. He was wrong about everything after it.
I came into that meeting leaning the same way he did, honestly. For a 90-person move, manual feels doable on a whiteboard. Three calls and one spreadsheet later, I had changed my mind. PST round-trips lose calendar permissions and corrupt large mailboxes more often than anyone admits. The script for SharePoint does not carry version history or the sharing links people depend on. And rebuilding six Teams by hand means losing the chat history the lending team uses to remember why a loan was structured a certain way.
The real cost of manual is not money. It is the two weeks of half-broken email in the middle, the lost audit trail, and the senior admin who burns out doing 490 moves at 11 PM. Here is the trade-off we put on one slide.
| Approach | What you pay | What breaks | Fit for 490 users |
|---|---|---|---|
| Manual PST and scripts | No licence, heavy admin hours | Calendar permissions, version history, Teams chat, audit trail | Poor |
| Outside consultant, fully managed | Highest cash cost | Little, but you depend on their calendar, not yours | Works, expensive |
| BitTitan MigrationWiz, run in-house | Per-user licence, modest admin time | Few surprises with coexistence on | Strong |
Why MigrationWiz won the room
BitTitan MigrationWiz moves the objects, not a guess at the objects. It reads the source tenant, maps users to the destination, and migrates mailboxes, OneDrive, SharePoint, and Teams with the metadata that makes them usable. We turned on mailbox coexistence first, so that during the cutover a Chennai user emailing a Bengaluru user did not bounce. That single feature is what keeps the business running while the move happens underneath.
Two things mattered most for this deal. First, throttling and batching. You do not move 490 mailboxes in one night. You move them in waves, and the tool retries the items Microsoft rate-limits without you babysitting it. Second, the migration runs against documented Microsoft 365 tenant-to-tenant paths, so we were inside the lines, not improvising. Microsoft’s own tenant-to-tenant migration guidance and the BitTitan project model agreed on the order of operations, which is rare and reassuring.
For the personal-data piece, we logged every batch. Who moved, what moved, when. That log is not bureaucracy. It is the answer you hand an auditor or, under the DPDP framework, a regulator, when they ask how customer data was handled during the merge. ISO 27001 thinking helped here too; the control is in ISO/IEC 27001, and an audit trail is how you prove it.
We have run tenant-to-tenant moves for Indian SaaS, BFSI, and manufacturing teams.
The 60-day plan, week by week
Weeks one and two were discovery and identity. Map every user, decide the new email addresses, plan the directory and conditional access in the destination tenant. No data moved yet. This is the part people skip and regret.
Weeks three and four were pilots. We moved 20 friendly users, the ones who would tell us the truth, and ran them in coexistence for a full week. We caught two things: a shared calendar that needed re-permissioning and a SharePoint library with sharing links that had to be re-issued. Better to find that on 20 people than 490.
Weeks five through eight were the waves. Department by department, finance last because of the audit-sensitive shared mailbox. We kept coexistence on the whole time, so nobody lost the ability to email a colleague mid-migration. The senior admin who wanted to do it by hand ran the batches from his desk by 6 PM and went home. That, to me, was the proof.
The Chennai head of ops put it plainly afterward. “We expected two weeks of chaos. We got a few annoying days.” That is what a tool buys you. Not zero friction. Fewer surprises, and a calendar you control.
What I would watch on yours
One thing to watch: licensing in the destination tenant. Make sure every user you move has a licence waiting, or the mailbox lands and then sits unusable. Check the per-user counts twice before the big waves. Pakka, that one catches teams every cycle.
The other is post-move governance. Once 490 people share one tenant, permissions sprawl fast, which is its own project. We handled the cleanup the way a Hyderabad SaaS team did in a permissions audit day, and we made sure backup retention covered the new combined estate, the lesson from a Bengaluru mailbox-gone Monday.
If you want the brand-and-tooling overview behind all of this, that lives on our BitTitan MigrationWiz India page, and the wider stack sits under cloud solutions. If customer data is involved, start with a DPDP readiness check before the first batch moves.
Key takeaways
- Tenants do not merge. You move objects into one and retire the other. Say that to leadership early.
- Identity travels separately from mailboxes. Plan the directory first or users land locked out.
- Coexistence during cutover is the feature that keeps the business running.
- A migration moves personal data. Log every batch so the DPDP and audit answer is ready.
FAQ
How long does a tenant to tenant migration after acquisition take?
For a 490-user, two-tenant move with full files and Teams, plan 8 to 10 working weeks end to end. Discovery and identity take longer than the mailbox moves people fixate on.
Can we avoid downtime during the move?
You can avoid hard downtime. Turn on mailbox coexistence so cross-tenant email keeps flowing while you migrate in waves. Users feel a few annoying days, not a blackout.
Does BitTitan MigrationWiz move Teams and SharePoint, not just email?
Yes. It migrates mailboxes, OneDrive, SharePoint sites, and Teams with their metadata. The order of operations matters, which is why we pilot a small group first.
What about DPDP and customer data during the migration?
Treat the move as a controlled transfer of personal data. Keep a batch-level log of what moved and when, and run a readiness check before you start. That log is your evidence if a regulator asks.
Free migration scoping call. We map your two tenants and give you a realistic 60-day plan, no obligation.
P.S. Sudeep here. We ran a merge like this for a lending team last quarter, and the question their IT head asked is probably the one you are sitting with right now: do we risk doing it ourselves, or get help and sleep? Reach us on WhatsApp at +91 91375 93228 during 10-7 IST, or use the button above. We will tell you straight whether your move needs a tool at all.
