Guyana Lite and Metro Office & Computer Supplies - Retail and Distribution
Moving 138 GB of business email off shared hosting without losing a message
Two businesses were running years of operational email on shared web hosting, where mail competed with websites for the same resources and deliverability was quietly degrading.
Updated · By Timothy Indarsingh
Case Study
Proving the pipeline on the small domain before touching the big one
Two businesses held years of operational email in shared web hosting mailboxes. One domain carried 5 GB across a handful of active users. The other carried 133 GB across 36 mailboxes and could not be interrupted.
Firelinkx migrated both to dedicated mail hosting. The work was deliberately sequenced. The smaller domain went first and served as a live rehearsal for the pipeline, the verification method, and the DNS cutover procedure. Only once that domain was stable and delivering did the larger account begin.
That sequencing paid for itself twice. The first migration exposed a mailbox quota sizing error and an authentication limitation on the source host. Both were solved on the domain where a mistake cost little, and the fixes were carried into the migration where a mistake would have been expensive.
The Challenge
Shared web hosting treats mail as a side feature of a website plan, and both accounts were showing the consequences.
Mail and website files shared one storage allowance, so nobody could say what the mail alone actually weighed. Discovery found the smaller domain held 5 GB of mail, not the 7 GB the hosting panel implied. The larger domain held 133 GB across 36 mailboxes, with single boxes running to 27 GB.
Deliverability had degraded without anyone noticing. The larger domain published no SPF record, no DMARC policy and no visible DKIM key. Mail leaving that domain had none of the signals receiving servers now expect.
The constraint that shaped the whole project was access. The larger account was mission critical and its passwords could not be changed, because 32 staff would have been locked out of their own mail during a working week. Standard migration tooling wants either each user's password or a server-side master credential, and neither was available.
Project Goals
The migration had to move everything, prove it moved everything, and stay invisible to staff.
Move every message and every folder
Migrate complete mailbox history including Sent, Drafts, Junk, Trash and Archive folders, with folder structure preserved on arrival.
Change no passwords on the critical account
Move 32 mailboxes without a single credential change, so no member of staff loses access to mail or has to reconfigure anything mid-week.
Prove parity rather than assume it
Finish each mailbox with a verification pass that reports message counts on both sides and confirms nothing is missing on the destination.
Improve deliverability as part of the move
Publish correct SPF and DKIM records for domains that had been sending without them, and stage every DNS change so mail flow is never at risk.
Keep a full backup independent of both hosts
Hold a complete copy of the source mail outside the old host and the new one for the duration of the project.
The Solution
Two different source hosts required two different methods, decided by what each one would allow.
The smaller domain ran on a host with server-side master authentication disabled. That left password rotation as the only route, which was acceptable for five mailboxes belonging to users who could be warned in advance. Each password was rotated through the hosting control panel API over SSH, so no existing password had to be known.
The larger domain could not absorb that disruption. Firelinkx used an indirect route instead. The complete mail directory was mirrored to a managed VPS over SSH, a local IMAP server was pointed at that mirror, and the migration tool synchronised from the local server to the destination. The source host was only ever read from, and not one password changed.
The mirror did double duty. It was the migration source and it was the disaster recovery copy, held on infrastructure separate from both hosts for the duration of the migration.
What Discovery Turned Up
An inventory pass before any data moved changed the shape of the project.
Fifteen mailboxes that had never been used
An activity scan against mailbox timestamps found 11 boxes on one domain holding a single welcome message from 2020 or 2021, and 4 dormant boxes on the other. All were dropped from the migration and preserved in the backup.
A dormant mailing list
The larger domain ran a Mailman list the destination platform does not support. It had three internal members and one message since 2020, so it was replaced with a plain forwarder instead of a list service.
A retired address kept as an alias
One retired address had taken no real mail since 2022 but remained published. It was recreated as an alias to a live mailbox so stray order and system mail would not bounce.
Missing sender authentication
The larger domain had no SPF, no DMARC and no DKIM. These were published as the first stage of the DNS work, well before any mail routing changed.
The Diagnosis That Was Wrong
Part way through the large migration, thousands of messages began failing to transfer, and the first explanation was incorrect.
Messages on the source host had file sizes smaller than the size recorded in their own filenames. The mirror was byte for byte identical to the source, so the discrepancy was real. The working conclusion was corruption on the old host, affecting mostly historic drafts and sent mail. A note to the client was drafted on that basis.
That conclusion was wrong, and it was caught before it was sent. The affected files began with the gzip magic number, and their decompressed size matched the filename claim exactly. The old host stored mail compressed, and the intermediate IMAP server had been set up without the plugin needed to read it. Nothing was corrupt and nothing was lost.
The consequence mattered more than the misdiagnosis. Because compressed messages had been unreadable, the first pass had skipped them silently, and a run reporting no errors was not a complete run. Enabling compression support and re-running every mailbox was the actual completion sweep.
Verification and Cutover
Every mailbox finished with evidence, and DNS changed in stages so mail flow was never in question.
A parity sweep across every mailbox
The final verification pass ran all 32 mailboxes on the larger domain and returned a clean result on each one, with no messages missing on the destination and no transfer errors.
Quotas sized from real measurements
The first migration stalled when a mailbox filled its allowance, because IMAP reported more than the disk usage estimate. Destination quotas on the second domain were set well above measured usage from the start.
DNS changed in three stages
Authentication records were published first, with no effect on routing. Mail routing moved second, and only after every mailbox had been verified. Decommissioning the old host is the final stage and follows a fortnight of confirmed delivery on the new platform.
Delivery tested as a real sender
After the first domain cut over, an external message was delivered over plain SMTP the way another mail server would send it, and confirmed to arrive in the destination inbox.
Outcome
Both domains are live on dedicated mail hosting, with every mailbox verified against its source before the switch.
Each domain cut over the same way. Mail routing moved only after every mailbox had been confirmed complete on the destination, and because the records carried short lifetimes the change reached public resolvers within minutes. Synchronisation continued on a defined schedule afterwards, at six hours, one day, two days, three days and a week, so anything still arriving at the old host was collected and any late delivery would be visible.
The larger domain moved its full 133 GB across 32 mailboxes without a single password change. Staff kept working through the migration and needed nothing reconfigured, because the only change on switch day was the address of the webmail they sign in to.
Both businesses are off a platform where mail competed with websites for resources. Mailbox storage is now sized for mail, sender authentication is published and correct, and a complete copy of the original mail was held independently of both hosts throughout the migration.
Services Delivered
Need a System Like This?
Let's discuss the workflow, controls, and outcomes your business needs.