Before You Migrate

1. Define the reason for the move

Migration is an operating-model change, not a file transfer. Define the business constraint, the risk to reduce, and the measurable outcome the new platform must support.

• Name what is failing today and what must improve after launch.
• Decide what will be preserved, redesigned, retired, archived, or deferred.
• Set leadership-level measures for value, adoption, quality, and time to execution.

2. Build the current-state inventory

Do not begin by moving everything. Establish an evidence-based inventory of the environment, including the assets and operating practices that are easy to miss in a technical workstream.

• Campaigns, journeys, workflows, templates, forms, scoring, routing, and approvals.
• Audiences, identity, consent, preferences, suppression, and historical data.
• CRM, warehouse, analytics, advertising, content, partner, and middleware integrations.
• Reports, dashboards, attribution models, permissions, environments, owners, and standards.

3. Make the migration decision visible

Every asset should have a disposition and an accountable owner. A one-to-one copy carries forward complexity; a deliberate disposition plan creates room for a better design.

• Migrate when the capability is still needed and the implementation is fit for purpose.
• Redesign when the outcome matters but the current process creates avoidable cost or risk.
• Retire or archive when the capability is unused, unsupported, duplicative, or required only for history.
• Defer when the capability is valuable but not necessary for a stable first release.

4. Protect data, identity, and consent

Data decisions define migration risk. Agree on ownership, mapping, transformation, quality thresholds, and validation before records move. Privacy and access controls belong in the design baseline.

• Define systems of record for identity, customer status, revenue, consent, and eligibility.
• Document field mappings, required values, history rules, deduplication, and reconciliation.
• Separate active, inactive, duplicate, invalid, restricted, and regulated records.
• Preserve consent, subscription, suppression, deletion, retention, and regional requirements.
• Test roles and sensitive-data visibility in the destination environment.

5. Rebuild integrations and operating controls

An integration is not ready because it connects once. Define how it behaves at launch, under failure, and after the project team has moved on.

• Record direction, frequency, volume, latency, authentication, owners, and business impact.
• Separate launch-critical connections from later-phase requirements.
• Specify monitoring, alerting, retries, failure handling, escalation, and support ownership.
• Set naming, templates, approvals, release, QA, change-control, and documentation standards.

6. Sequence the work around the minimum viable launch

A phased migration reduces risk and gives the team evidence before scope expands. Establish the foundation first, then move the use cases that create the clearest business value.

• Discovery, inventory, architecture, data rules, and migration design.
• Configuration, integration foundations, priority assets, permissions, and reporting.
• Training, launch rehearsal, cutover, stabilization, and controlled optimization.

7. Test the operational reality

Testing should mirror the conditions operators will face. Validate the happy path and the situations that expose weak controls: missing data, duplicates, unsubscribes, failed integrations, conflicts, and incorrect permissions.

• Reconcile counts, values, relationships, consent, suppression, and historical records.
• Run end-to-end workflows through forms, CRM, integrations, notifications, and reporting.
• Verify approvals, audit history, exports, access restrictions, and failure recovery.
• Rehearse cutover and document contingency, rollback, and decision authority.

8. Enable the people who inherit the platform

The migration is not complete when the system is live. Operators need role-specific training, usable documentation, support access, and a clear definition of the new operating model.

• Train administrators, operators, approvers, analysts, and leadership on their responsibilities.
• Provide standards, templates, office hours, escalation paths, and feedback loops.
• Measure adoption, production quality, support demand, and time to complete priority work.

9. Stabilize before optimizing

Treat the first weeks after launch as a managed stabilization period. Monitor the environment, triage defects, record decisions, and distinguish launch issues from later enhancements.

• Watch integrations, deliverability, data quality, workflow errors, and reporting reconciliation.
• Assign owners, priorities, response targets, and escalation paths for issues.
• Retire the legacy environment only after retention, access, and continuity requirements are met.

Migration-readiness gate

• Business outcomes and launch measures are documented
• Owners, decision rights, and operating responsibilities are named
• Assets, data, integrations, reports, permissions, and dependencies are inventoried
• Every item has a migrate, redesign, retire, archive, or defer disposition
• Data mappings, identity rules, consent, and source-of-truth ownership are approved
• Critical integrations have monitoring, failure handling, and test evidence
• Governance, QA, launch scope, and phased roadmap are agreed
• End-to-end testing, reconciliation, cutover rehearsal, and contingency plans are complete
• Users have role-specific training, documentation, and post-launch support
• A stabilization plan is in place before legacy systems are retired