7 Many large mail platforms still run on NAS. It served them well for years, but at millions of mailboxes and billions of files, NAS brings metadata bottlenecks, expensive array upgrades, slow backups and a disruptive migration at every hardware refresh. Moving to object storage solves most of those problems, but migrating a live mail platform is a delicate job. Users expect mail to keep working throughout, and no one wants to explain a lost message to a business customer. This article lays out a practical approach to migrate mail storage to object storage, based on the patterns providers commonly use: plan carefully, pilot with real users, move users incrementally with verification and keep a rollback path until the old storage is retired. For background on why providers make this move, see our hub on email storage architecture. Why migrate at all The decision usually starts with one of these triggers: The NAS platform is approaching end of support, and the replacement would be another large array purchase. File counts have grown to the point where metadata operations slow down during peak hours. Backups of billions of small files no longer complete in their window. NFS locking and mount issues cause intermittent mail errors. The provider wants to consolidate several storage islands from acquisitions or regions into one platform. Object storage scales out by adding nodes, handles billions of objects, protects data with erasure coding and supports hardware refresh without migrating data again. Once mail is on object storage, the next refresh is a rolling replacement of nodes rather than another migration project. Step 1: Inventory and baseline Before planning moves, understand the current platform in detail: Mailbox count and size distribution, including the largest mailboxes, which take longest to move. Mailbox formats in use, such as Maildir or dbox, and any variations between clusters. File and message counts, which drive migration time as much as capacity does. Growth and change rates, so you know how much new mail arrives during migration. Peak and off-peak activity, to schedule moves when users are least active. Dependencies: backup systems, archive capture, search indexes, quota systems, monitoring and support tools that read the mail store directly. Record performance baselines for login time, folder sync and message fetch. You will compare against them after migration. Step 2: Design the target platform Decide how the new platform will work before moving anyone: Mail server software and storage driver. Object storage support depends on the mail server platform and its storage driver. Confirm that your mail server supports an S3-compatible backend, and test it at realistic scale before migrating. Object storage backend sizing for capacity, small-object request rates and growth, including protection overhead. Local cache sizing on mail servers for indexes and recently read messages. Proxy and routing so each user can be pointed at old or new storage individually. Multi-site design and data protection. Backup and recovery for the new platform, which may look very different from file-based backup. Step 3: Choose a migration method Common approaches include: Mail server native sync. Mail servers often include tools that copy a mailbox between storage formats or backends while preserving folders, flags and unique identifiers. This is usually the preferred route because it understands mail semantics. IMAP-level sync tools, which copy mail between two servers over IMAP. These are flexible but slower and may not preserve every attribute. Bulk copy plus delta sync, where a mailbox is copied while live and a final short sync runs during a brief lock. Preserving message unique identifiers (UIDs) and flags matters. If UIDs change, mail clients may resynchronize entire mailboxes, which creates a flood of traffic and can confuse users with duplicate messages. Step 4: Pilot with real users Start with internal staff and a small group of friendly users. A pilot should test: Migration speed for small, average and very large mailboxes. Client behavior after migration across webmail, mobile and desktop clients. Performance against the baseline for logins, syncs and fetches. Delivery and expunge behavior on the new platform. Support workflows, such as restoring deleted mail. Monitoring and alerting. Fix issues and adjust cache sizes and tuning before scaling up. Step 5: Move users in waves Once the pilot is stable, migrate in waves of increasing size. A typical per-user flow: Run an initial copy of the user’s mailbox from NAS to object storage while the user stays on the old platform. Run incremental syncs to catch new mail. Briefly lock the mailbox, run a final sync and switch the user’s routing to the new platform. Verify the result automatically. Keep the old copy read-only for a defined period in case of rollback. Automate each step. At millions of users, manual handling is impossible, and the migration tooling should track each user’s state, retry failures and report exceptions. Scheduling and throttling Migration traffic competes with production. Throttle copy rates during peak hours, schedule large mailboxes overnight and monitor both NAS and object storage load. NAS platforms that are already near their limits can be pushed over the edge by aggressive migration reads, so be conservative early and increase rates as confidence grows. The scality.com blog’s article on S3 migration covers general throughput planning. Step 6: Verify every mailbox Verification protects against silent loss. Automated checks per user should compare: Message counts per folder. Total mailbox size within expected tolerance after compression differences. Folder structure and subscriptions. Flags and UIDs for a sample of messages, or all messages for high-value accounts. Successful login and folder listing on the new platform. Log results and hold back users that fail verification for investigation. A migration report per wave gives management and support a clear view of progress. Step 7: Keep a rollback path Until the old platform is retired, keep the ability to send a user back. Practical measures include: Leaving old mailbox copies read-only rather than deleting them immediately. Making routing changes reversible per user. Defining criteria for rollback, such as repeated client errors or failed verification. Rollback should be rare, but having it available makes the migration far less risky and helps win approval from stakeholders. Step 8: Update the surrounding systems The mail store rarely stands alone. As users move, make sure: Backup covers migrated users on the new platform. Archive capture continues for business customers. Search indexes are rebuilt or migrated. Quota reporting, support tools and monitoring read from the new platform. Billing and provisioning systems create new users directly on object storage. Step 9: Retire the NAS When all users are migrated and the rollback window has passed, retire the old storage. Securely delete mail data from the NAS according to your data protection obligations and document the process. data deletion verification covers how to evidence deletion. How long does it take? Duration depends on the number of mailboxes, total messages, migration throughput and how conservatively you throttle. Large platforms often plan migrations over months, with the pilot and first waves taking longer while tooling matures, and later waves moving much faster. The constraint is usually NAS read performance and message count rather than capacity. Common pitfalls Changing UIDs, which triggers full client resyncs. Underestimating very large mailboxes, which can take far longer than average ones. Ignoring dependencies that read the NAS directly, such as backup or archiving jobs. Overloading the NAS with migration reads during peak hours. Skipping verification for speed. Undersized caches on new mail servers, which push too much load to the object store. Checklist: migrate mail storage to object storage Inventory mailboxes, formats, file counts and dependencies. Record performance baselines. Design the target platform, caches, routing and backup. Choose a migration method that preserves UIDs and flags. Pilot with internal and friendly users. Automate per-user copy, sync, cutover and verification. Throttle migration around peak hours. Keep old copies read-only for a rollback window. Update backup, archive, search, support and provisioning systems. Securely retire the NAS and document deletion. Putting it together To migrate mail storage to object storage successfully, treat it as a series of small, verified moves rather than one big switch. Inventory carefully, design the target platform around caching and scale-out storage, pilot with real users, automate per-user moves and verification and keep a rollback path until the end. Done this way, users notice little beyond better performance, and the provider ends up on a platform that will not need another forklift migration at the next refresh. Frequently asked questions Can mail be migrated to object storage without downtime? Yes, typically user by user, with an initial live copy, incremental syncs and a brief lock for the final sync and routing switch. Why do UIDs matter in a mail migration? Mail clients use UIDs to track messages. If they change, clients may download entire mailboxes again, creating heavy load and possible duplicates. How do you verify a migrated mailbox? Compare message counts, folder structures, sizes, flags and UIDs between source and target, and confirm the user can log in and list folders. What usually limits migration speed? Often NAS read performance and the number of small files, rather than raw capacity. What happens to backups during migration? Backup must cover users on both platforms during the transition, and the backup approach for object storage may differ from file-based backup. Further reading Email storage architecture Scaling mailbox storage Email archiving vs email backup Cold data migration strategy
