KoltrixBudgeting for an Email Migration: Time, Tools and Risk
An email migration costs more than the new subscription. A worksheet for the hours, overlap fees, archive storage, tools and risk buffer to plan for up front.
On this page(8 sections)
Most email migration decisions compare one number: the new provider's monthly price against the old one's. That comparison leaves out nearly everything the move actually costs, and it's why migrations that looked like an easy saving end up taking a month of someone's evenings.
This post is a worksheet for the one-off costs of switching email providers, so you can decide with the full picture, and so you know where the time will go before you start.
The five cost buckets
A migration's cost falls into five buckets. Only one of them shows up on an invoice from the new vendor.
| Bucket | What it covers | Often overlooked because |
|---|---|---|
| People time | Planning, DNS work, testing, migrating data, helping colleagues | Nobody bills for it |
| Overlap | Paying the old and new provider at the same time | Contracts don't end the day you switch |
| Archive | Exporting, storing and keeping access to old mail | It's needed years later, not now |
| Tools | Migration services, export utilities, consultant help | Depends on what the new provider supports |
| Risk buffer | Lost mail, downtime, rework | Hard to estimate, so it's left at zero |
Work through each one for your situation. The numbers will differ widely between a two-person startup and a fifty-person company, but the buckets are the same.
Bucket 1: people time
This is usually the largest cost, and the one most often guessed at. Break it into tasks and estimate hours for each.
- Inventory. Listing every mailbox, alias, group, shared address and system that sends as your domain. Our post on inventorying everything that sends as you covers how. For a small company this is a few hours; for one with years of integrations it can be days.
- Setting up the new provider. Creating addresses, configuring domains and publishing DNS records.
- Updating integrations. Your help desk, CRM, billing system, forms and application all need checking, and some need new credentials or SPF entries.
- Testing. Sending and receiving with major mailbox providers, checking authentication, testing every shared address.
- Moving data. Exporting old mail and, where the new provider supports it, importing it.
- Helping people. Answering questions, setting up devices, re-creating filters and signatures. Multiply a small amount per person by everyone affected.
- Cut-over and the days after. Being available when MX changes and dealing with whatever comes up in the following week.
Write down an hourly cost for internal time, even if it's a founder's. "Free because I'll do it myself" is how a migration quietly displaces a week of product work.
Bucket 2: the overlap period
You'll pay both providers for a while. That's normal and sensible: the old account stays live during cut-over, provides a fallback if something goes wrong, and gives everyone time to retrieve anything they forgot.
Check three things in the old contract:
- Billing cycle and notice period. Annual plans may not refund unused months. Monthly plans may require notice before the next cycle.
- What happens to data at cancellation. Some providers delete mail soon after cancellation; others keep it for a while. Know the date before you rely on the old account as an archive.
- Downgrade options. Some providers let you drop to a cheaper tier or fewer users for the overlap, which can reduce the cost of keeping the old account read-only.
A typical plan is to overlap for at least one full billing cycle after cut-over, and longer if you're keeping the old account as your archive.
Bucket 3: the archive
Old email has a long tail of value: contracts, receipts, customer history, legal holds. You need a plan for keeping it accessible after the old provider is gone.
Options, roughly from cheapest to most convenient:
- Export and store. Export each mailbox (commonly to MBOX or PST format) and keep the files in secure, backed-up storage. Cheap, but searching them later is awkward.
- Keep the old account read-only. Convenient for searching, but you keep paying.
- Import into the new provider. Everything in one place, if the new provider supports importing. Not all do. Koltrix, for example, has no mailbox importer in its first release, so moving to it means planning for one of the other options.
Budget the storage, any retention requirements your business has, and a little time each year to confirm the archive still opens.
Bucket 4: tools and outside help
Depending on the providers involved, you may pay for:
- A third-party migration service that copies mailboxes between providers
- Export utilities or a desktop mail client to pull mail over IMAP
- A consultant or IT provider to handle DNS, Microsoft 365 or Google Workspace admin tasks you'd rather not learn
For small teams, these are often optional; for larger ones with many mailboxes, a migration service can cost less than the staff time it saves. Get quotes based on mailbox count and data volume.
Bucket 5: the risk buffer
Things go wrong in migrations: an MX record with a long TTL, a forgotten alias that silently stops receiving, an integration that breaks because it was sending through the old provider. Each of these costs time to fix and sometimes costs a missed customer email.
You can shrink the risk with good process: lowering DNS TTLs in advance, keeping the old provider live, having a written rollback plan, and testing every address after cut-over. But leave a buffer anyway. A common approach is to add a fixed percentage on top of the people-time estimate; pick a figure that reflects how complicated your setup is and how much you trust your inventory.
A worksheet to copy
| Line item | How to estimate | Your number |
|---|---|---|
| Inventory | Hours x internal rate | |
| New provider setup and DNS | Hours x internal rate | |
| Integration updates | Number of systems x hours each x rate | |
| Testing | Hours x rate | |
| Data export and import | Mailboxes x hours each x rate | |
| User support | People x hours each x rate | |
| Cut-over and aftercare | Hours x rate | |
| Overlap fees | Old monthly cost x overlap months | |
| Archive storage | Storage cost x years retained | |
| Tools and services | Quotes | |
| Risk buffer | Percentage of people-time total | |
| One-off total | Sum of the above |
Then compare the one-off total against the ongoing difference in monthly cost (and any time the new setup saves each month). If the new provider saves a modest amount per month and the migration costs several months of that saving, the move has to be justified by something else: better features, fewer vendors, or less time spent fighting the old system.
Bottom line
- The subscription price is the smallest part of most email migrations.
- Budget five buckets: people time, overlap, archive, tools and a risk buffer.
- Put an hourly value on internal time, including founders'.
- Plan the archive before you cancel anything, especially if the new provider can't import old mail.
- Compare the one-off total with the ongoing saving. A migration should pay for itself in a time frame you can accept.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
