Checklist: move email archives to cloud storage

Who this is for

You are holding email that no longer sits in a live mailbox. It might be PST and OST files on a file share, a journal mailbox nobody has opened since an old Exchange server was retired, an archive appliance in a rack, or exports from a mail gateway. The mailbox is gone, but the records are still yours to find, keep and eventually delete.

This is for the IT lead who will run the move, the sysadmin who knows where the files are, and the finance or operations person who signs off on storage spend and retention. It assumes you are moving archives, not live mailboxes. A tenant to tenant mailbox migration is a different job with different tools.

The Checklist: move email archives to cloud storage below runs in the order that keeps you out of trouble. Read it end to end before you touch anything. Most archive projects go wrong in the first week, when someone bulk copies a decade of PST files into a bucket and calls it finished.

Before you begin

Count what you have before you promise anything: file count, total size, earliest and latest message date, and the format of each source. Old archives hide in places people forget. Local drives on retired laptops, tape sets, shared folders named after people who left, and export folders from the mail gateway.

Decide the shape of the target. Broadly you have two choices. Object storage such as S3, Azure Blob or Google Cloud Storage holds the bytes cheaply but gives you no search and no mail client, so you build the index and the reader yourself. A cloud archive service gives you search, holds and a viewer out of the box, with a fee per user or per gigabyte. Pick one deliberately, because switching later means moving everything twice.

Build the owner map. For each archive file or journaling range, record which person, department or case it belongs to. File names lie, and one PST often holds several mailboxes. If nobody can say who owns a file, it is a candidate for deletion rather than migration.

Agree the retention rules before the first byte moves. Talk to whoever handles legal hold and compliance in your company and write down what must be kept, for how long and who can delete it. Changing retention after migration is possible, but far more expensive than setting it once.

The checklist

Work source by source, in batches small enough to verify. One department or one journal year is easier to check than a single 400 GB copy job.

Run the steps below in order for each batch. Keep the originals read only while you work. That stops anyone editing a PST mid flight and gives you a clean fallback if a batch fails.

Do not delete a source until the batch passes verification and someone has signed it off in writing.

Expect one round of rework. A PST that opens in Outlook can still fail halfway through an export, and finding that early is the whole point of testing a small batch first.

• Inventory every archive source: file shares, laptop drives, journal mailboxes, appliance exports and backup tapes.
• Record file count, total size, earliest and latest message date and format for each source in one spreadsheet.
• Open a sample of PST files with a repair tool such as scanpst, so you find corruption before it reaches the target.
• Map each file or journal range to an owner, department or case reference.
• Choose the target, either object storage with your own index or a cloud archive service with search built in.
• Time a test export of one small batch so you can size the rest of the job.
• Convert messages to a neutral format such as EML or MBOX, or load them through the archive service import tool.
• Write a manifest per batch with source path, file hash, message count, date range and target location.
• Load the batch, then compare message counts and checksums between source and target.
• Build a full text index over subject, sender, recipients, body text and attachment names.
• Mirror the old mailbox permissions so search results do not leak between departments.
• Set retention and deletion rules in the target before the first search goes live.
• Run three test searches per batch: a known sender, a known phrase from a body and a known attachment name.
• Keep the source read only, get written sign off, then delete it and record the date.

What good looks like

A colleague asks for a message from 2009 and finds it in under a minute from a browser, with nobody opening a PST. That is the test that matters. If finding mail still means mounting a file share and waiting for Outlook, the archive has moved but it is not usable.

Every batch has a manifest with source path, hash, message count, date range and target location, and the counts match. Keep those manifests with the project documents. They are what you show when someone asks whether a particular message survived.

The storage bill is boring and predictable. Older mail sits in a cold tier, there is one copy plus a backup, and nothing is stored twice because two teams each migrated the same folder.

Access is reviewed and current. Archives of people who left are assigned to a manager or a case owner, not left on an admin account that nobody watches.

What to do next

Start with one batch this week. Pick a single department or one year of journal mail, run the full checklist against it and time each step. You will learn more from that than from another planning meeting.

Write down the restore path before you finish. How does a single message get back into an active mailbox in five minutes, and who runs it? If the answer is vague, fix that before you decommission anything.

You can run this in house, bring in a contractor, or buy a scoped piece of work to settle the architecture first. One option is the Cloudverg Discovery and roadmap sprint at $9,500 fixed price, a two week engagement that ends with a target architecture, a phased plan and a fixed quote for phase one. It suits teams who know the archives exist but cannot yet say what the target should look like.

Frequently asked questions