The visible inventory is never the complete system
Large migrations are often described with a simple before and after.
A company is moving from one CMS to another, from one cloud edge provider to another, from a custom platform to HubSpot, or from an older application architecture to a new one. The project can look like a transfer problem: identify what exists, recreate it somewhere else, and switch traffic.
That description misses most of the risk.
An enterprise platform accumulates relationships over time. URLs are indexed and linked from other systems. Forms feed downstream workflows. DNS records, certificates, caching behavior, redirects, analytics, consent tooling, integrations, scheduled jobs, and operational procedures all depend on decisions that may not be documented in one place.
The migration is not only moving the visible asset. It is changing a connected operating system.
Start with dependencies, not page counts
Page counts and repository sizes are useful planning inputs, but they do not reveal where a migration can damage the business.
The first useful inventory should identify:
- domains, subdomains, routes, and redirect behavior;
- origin services, edge rules, DNS, certificates, and caching;
- forms, APIs, webhooks, and third-party integrations;
- authentication, permissions, and protected content;
- analytics, consent, advertising, and campaign dependencies;
- structured content types and their reuse across channels;
- scheduled processes and background jobs;
- business owners and technical owners for critical workflows; and
- current monitoring, recovery, and escalation paths.
This inventory should not become an endless documentation exercise. Its purpose is to find the seams where a technically successful cutover could still create an operational failure.
A ten-page site with one revenue-critical application can carry more migration risk than a thousand-page publishing archive.
Define parity before rebuilding
Teams often use the word parity without agreeing on what it means.
Visual parity is only one dimension. A migrated system may look correct while changing cache behavior, dropping analytics events, weakening redirects, altering form validation, or breaking a downstream process.
Useful parity criteria describe observable behavior:
- which routes must continue to resolve;
- which redirects must preserve status and destination;
- which forms must accept or reject specific inputs;
- which events must reach analytics and marketing systems;
- which headers, certificates, and security controls must remain present;
- which performance thresholds must hold; and
- which operator workflows must continue without manual intervention.
Once parity is explicit, it becomes testable. It also becomes easier to decide where intentional improvement is allowed instead of accidentally treating every historical behavior as sacred.
Migrate in waves when the system allows it
The safest migration is usually not one giant moment.
Teams can often divide the work by domain, content type, business unit, traffic segment, or technical capability. A smaller wave exposes incorrect assumptions while the blast radius is still manageable.
A migration wave should have:
- a defined inventory;
- entry criteria showing the target is ready;
- validation for representative and high-risk paths;
- a clear owner during the cutover;
- a rollback condition and mechanism; and
- a short observation window before the next wave.
Not every platform supports clean parallel operation. Even then, rehearsal helps. Teams can run synthetic traffic, compare headers and response behavior, test redirects from a captured URL corpus, exercise forms against non-production destinations, and validate certificates before the public switch.
The point is to make the migration produce evidence before it produces irreversible confidence.
Content migration needs a model, not only a script
CMS migrations introduce another common trap: treating content as interchangeable rows.
The source system may encode meaning through templates, naming conventions, layout choices, or fields that only make sense in that platform. Copying those structures directly can recreate the old system’s limitations inside the new one.
Before automating the transfer, the team should decide:
- which content types are durable;
- which fields represent real meaning versus presentation;
- which relationships need to be preserved;
- which content is duplicated, stale, or legally required;
- which URLs need exact preservation; and
- which exceptions require editorial review.
Automation should handle repeatable transformations. Review queues should handle ambiguity. Combining both is more reliable than pretending every source record can be migrated with the same confidence.
Cutover is an operating event
The technical team cannot own a large migration alone.
Marketing may need campaign freezes or URL coordination. Security may need to validate certificates, access controls, and vendor boundaries. Legal or compliance teams may care about retention and consent. Support teams need to recognize migration-related symptoms. Business owners need to confirm that critical journeys still work.
A useful cutover plan names who is watching each signal, who can make a rollback decision, how status will be communicated, and what counts as a blocker.
That clarity matters because migration incidents are rarely solved by a single log line. They are resolved by people who understand which behavior matters and have enough authority to act.
Completion includes the period after launch
A successful switch is not the end of the migration.
The team still needs to watch error rates, redirect misses, form completion, cache behavior, certificate health, search traffic, analytics continuity, integration failures, and operator reports. Old infrastructure should remain available only as long as the rollback and retention plan requires, then be deliberately retired.
This is also the right time to update runbooks and ownership. A migration that leaves everyone following the old operating process is only partially complete.
The takeaway
Large enterprise migrations are coordination systems.
They connect architecture, content, infrastructure, security, analytics, integrations, and business operations around one controlled change. The transfer itself matters, but the quality of the migration is defined by what the organization can continue to trust afterward.
The strongest migration plans make dependencies visible, define behavior before rebuilding it, generate evidence in small steps, preserve a safe way back, and keep ownership clear through the cutover.
That is how a platform changes without forcing the business to rediscover everything it depended on.