How to Write a Specification for Zero-Downtime Corporate Email Migration

A specification for zero-downtime corporate email migration must define not only mailbox transfer, but also the mail-flow cutover procedure, change synchronization, readiness criteria, rollback scenario, and measurable acceptance conditions. The phrase “zero downtime” must be expressed through permissible metrics: users continue to send and receive messages, inbound email is not lost, and any temporary limitations are listed and approved in advance.

1. Document the Current and Target States

At the beginning of the specification, state the source and destination systems. Product names alone are not sufficient: the contractor needs the deployment architecture, domains, access methods, protocols, integrations, and constraints.

For the source system, document:

deployment type: on-premises infrastructure, cloud service, or hybrid architecture;
the list of email domains and subdomains;
the number of active, blocked, archived, and shared mailboxes;
the data volume of each mailbox and the total volume;
the presence of archives, calendars, contacts, tasks, rules, signatures, and delegation;
protocols and clients: web interface, SMTP, IMAP, POP3, ActiveSync, or proprietary APIs;
authentication sources: local accounts, directory services, single sign-on, and multi-factor authentication;
connected systems: CRM, ERP, service desk, scanners, MFPs, applications, and devices that send email;
retention, archiving, journaling, and incident investigation policies;
current DNS records that affect message delivery and authentication.

For the target system, specify the proposed architecture, licensing model, account provisioning method, domain requirements, supported migration methods, and limits on message, mailbox, and attachment sizes. Version-dependent parameters must be taken from the selected provider’s official documentation as of the design date.

The requirement to “migrate email with zero downtime” must not be accepted as a standalone criterion. The specification must separately define the permissible delivery delay, the maximum unavailability period for individual functions, how users will work during the cutover, and how the absence of data loss will be confirmed.

2. Define the Migration Scope

List the objects included in the project. For each data type, define the expected result and the verification method.

Object	What Must Be Migrated	How It Is Verified
Email messages	Folders, dates, senders, recipients, subjects, attachments, and read flags	Count reconciliation and sample content checks
Calendars	Events, recurrence patterns, attendees, and meeting rooms	Verification of test events and recurring meetings
Contacts	Personal and shared address books within the approved scope	Count reconciliation and verification of required fields
Delegation	Access to shared mailboxes, send-as permissions, and substitute access	Sign-in and sending tests for selected roles
Rules	Only rules supported by the target system	A list of migrated and excluded rules
Archives	Online archives or exported data in accordance with the retention policy	Verification of volume, date range, and search availability

Separately list what will not be migrated: obsolete rules, corrupted items, users’ local files, unsupported formats, deleted mailboxes, and data outside the defined retention period. For each exclusion, specify how it must be handled: deleted, exported, retained in an archive, or migrated manually.

3. Complete the Inventory Before Approving the Schedule

The schedule must not be calculated solely from the number of users. The specification must include a mandatory discovery phase whose output is a migration object register.

Minimum register fields:

User identifier
Primary address
Additional addresses
Mailbox type
Account status
Data volume
Item count
Archive availability
Delegation availability
User criticality
Department
Migration wave
Pre-migration validation result
Final validation result
Exception notes

The assessment must identify duplicate addresses, invalid domains, ownerless mailboxes, conflicting aliases, target-system limit violations, and applications that use the legacy server as an SMTP relay. Unidentified technical senders often cause failures only after the primary domain has been switched.

4. Describe the Zero-Downtime Migration Strategy

For most corporate projects, a phased migration is safer. The exact mechanism depends on the capabilities of the source and target platforms, so the specification must describe the process logic rather than unverified commands.

Preparation. Target accounts are created, and domains, permissions, licenses, addresses, and access policies are validated.
Initial synchronization. The main volume of historical data is copied before users are switched.
Pilot. A limited group representing both standard and complex scenarios is migrated: a regular user, an executive, a shared mailbox, a delegate, a mobile client, and a technical sender.
Migration waves. Users are migrated in groups based on departments, dependencies, and criticality.
Routing cutover. The route for new inbound messages and client access settings are changed.
Final synchronization. Changes created after the initial migration are copied.
Coexistence period. The source system remains available under the approved operating model until verification is complete.
Legacy system decommissioning. This is performed only after acceptance has been signed and the rollback period has expired.

The specification must state whether parallel delivery, cross-platform forwarding, or temporary use of the legacy system for specific groups is allowed. These capabilities depend on the selected products and licenses and must be confirmed against the vendors’ official documentation before the migration design is selected.

5. Define DNS and Email Authentication Requirements

Mail-flow cutover involves at least MX records and sender authentication mechanisms. The specification must identify the party responsible for DNS, the registrar or service provider, the permitted change window, and the procedure for restoring previous values.

The following must be included:

an inventory of current MX records;
SPF validation that includes all legitimate sending sources;
DKIM configuration on the target system;
verification of the DMARC policy and reporting addresses;
approval of DNS record time-to-live values before cutover;
retention of the original values for rollback;
monitoring of external delivery after routing is changed.

The specification must not require all old and new senders to be added mechanically to a single SPF record without validation. SPF has limitations defined by the standard, and an incorrect configuration can reduce deliverability. The final records must be validated by the responsible specialist against the actual infrastructure.

6. Describe the Pilot Migration

The pilot must be treated as a separate phase with its own test protocol. The group must include not only technical staff, but also users with different working scenarios.

Pilot testing must cover:

sign-in through the web interface and corporate clients;
sending within the organization and to external domains;
receiving messages from external senders;
replies, forwarding, and attachment handling;
calendar invitations and recurring meetings;
shared mailboxes, delegation, and send-on-behalf permissions;
mobile devices;
system notifications from applications, MFPs, and servers;
antispam, quarantine, journaling, and retention rules;
correct display of addresses, folders, and timestamps.

After the pilot, prepare a defect list that includes priority, owner, remediation deadline, and the decision on whether mass migration may proceed. Critical defects involving delivery, authentication, or data loss must block the next phase.

7. Establish Measurable Acceptance Criteria

The criteria must make it possible to accept or reject the result unambiguously. Do not use statements such as “email works correctly” or “all data has been migrated” without a verification method.

An example set of criteria:

all accounts in the approved register have been created in the target system;
a migration report containing the status and list of exceptions has been generated for each mailbox;
test messages are successfully delivered between internal and external addresses;
after cutover, new inbound messages are delivered to the target system;
users in the control sample can access the approved folders, messages, calendars, and contacts;
shared mailboxes and delegation work for the listed roles;
technical senders pass a separate test;
SPF, DKIM, and DMARC match the approved design;
all skipped or unsupported items are recorded and approved;
the support team has received instructions and access to diagnostic logs.

The acceptable error percentage must not be chosen arbitrarily. It must reflect the criticality of the data and include a handling rule for each failure. For legally significant or regulated messages, zero unexplained omissions may be required and confirmed through a separate reconciliation process.

8. Add a Rollback Scenario

Rollback must be prepared before the cutover begins. The specification must define the event that triggers the rollback decision, the person authorized to make that decision, and the maximum time allowed for remediation before rollback.

The scenario must include:

restoring the previous inbound email routing;
restoring the previous user access settings;
preserving messages delivered to the target system before rollback;
re-running synchronization after the root cause has been resolved;
notifying users and the support team;
recording the incident and selecting a new migration window.

Bidirectional synchronization requires special attention: it is not supported by all platforms and can create duplicates or conflicts. If the selected systems do not provide safe reverse copying, this limitation must be stated explicitly in the specification and reflected in the duration of the cutover period.

9. Assign Responsibilities

Assign owners for at least the following areas: source email system, target system, user directory, DNS, information security, user support, corporate applications, and project management.

For each phase, specify:

who performs the action;
who provides the data and access permissions;
who approves the result;
who decides whether to proceed or roll back;
which document confirms completion of the phase.

10. Define the Project Deliverables

The mandatory deliverables must include the approved mailbox register, migration design, schedule, pilot protocol, migration wave reports, exception list, delivery validation protocol, current DNS design, user instructions, support-team instructions, and acceptance certificate.

The source system must not be disabled immediately after the final migration wave. The retention period and access model must be defined by the organization’s policies, contractual obligations, security requirements, and data retention rules.

Final Specification Checklist

the source and target architectures are documented;
a complete register of mailboxes, addresses, and integrations has been prepared;
migrated and excluded data has been defined;
a phased migration design with initial and final synchronization has been selected;
a pilot with go/no-go criteria has been scheduled;
the MX, SPF, DKIM, and DMARC cutover is documented;
measurable acceptance criteria have been established;
a verifiable rollback scenario has been prepared;
owners have been assigned for DNS, systems, security, and support;
reports, instructions, and project closure documents have been defined;
platform-specific limitations are documented with links to official documentation;
decommissioning of the legacy system is permitted only after verification and the rollback period have been completed.