Data-Integrity Reconciliation After a CMS Migration: How to Prove Nothing Was Lost

You build defensible evidence that nothing material was lost by reconciling the new platform against a frozen pre-migration baseline – page by page, redirect by redirect, asset by asset, and locale by locale. That reconciliation should be a tracked deliverable with a named owner, not a QA exercise introduced during the final week before launch. Teams that establish the evidence trail during discovery can explain the status of every identified item; teams that do not often reach go-live with a large “missing pages” report and no reliable way to distinguish genuine gaps from stale records, planned retirements, or completed redirects. 

That second situation is more common than the industry admits. In most cases, the pages aren’t actually missing. The audit is just stale.

eight25 runs enterprise migrations from platforms such as Sitecore, AEM, and Tridion into Contentful and Contentstack, with content and redirect reconciliation scoped as a tracked deliverable from discovery. These platforms are particularly well suited to a controlled reconciliation process because structured content models, explicit locale handling, APIs, scripted migration tooling, and environment-based release workflows make content easier to classify, transform, test, and account for. Those capabilities do not prove completeness on their own, but they give migration teams a cleaner foundation for producing the evidence. What follows is the method we use to turn “nothing material was lost” into a claim that can be examined line by line rather than carried into cutover as an assumption.

Why “nothing was lost” is hard to prove, and why the fear is rational

Every VP signing off on a CMS migration carries a specific version of the same fear: what if we cut over, and something a customer needs (a compliance PDF, a product spec, a campaign landing page) quietly stopped existing? The fear is rational because the failure is usually invisible. Nothing crashes. The site loads. Traffic looks fine for a week. Then a regional sales lead emails asking why the datasheet they send to every prospect returns a 404.

Proving completeness is hard because of three moving targets most migration plans never fully pin down:

• The source estate is often bigger and messier than the brief suggests. An initial estimate of 5,000 pages can increase substantially once the team accounts for locale variants, indexed PDFs, undocumented microsites, duplicate URLs, campaign archives, and legacy content omitted from the original audit. You cannot demonstrate that the agreed migration scope was handled completely unless you first establish what that scope contains. 
• Content in a mature legacy implementation is often entangled with presentation rules, layout configuration, custom components, and page-specific authoring workarounds. Sitecore, AEM, and Tridion can all support structured content, but long-lived estates frequently contain records whose meaning depends on templates, rendering logic, or implementation-specific conventions. That is why matching record counts between the source and destination proves very little by itself. A migration into a structured, API-first platform such as Contentful or Contentstack creates an opportunity to separate reusable content from presentation, but reconciliation must still confirm that fields, references, metadata, assets, localisation states, and intended rendering behaviour survived the transformation. 
• Redirects and URLs are a separate problem from content. Content can migrate perfectly and traffic can still collapse if the URL a customer bookmarked, or Google indexed, now resolves to nothing. Content parity and URL parity are two different audits, and teams routinely conflate them.

Reconciliation is the discipline that connects these three controls: defining the source estate, validating the transformed content, and preserving the URLs through which users and search engines reach it. Here is what that work involves.

The pre-migration baseline: you cannot reconcile against nothing

Reconciliation is a comparison, and a comparison needs a controlled reference point. The first step is therefore to capture a timestamped baseline of the source estate before migration transformations begin, then maintain an explicit change log for content created, edited, retired, or redirected after that snapshot. A stricter publishing freeze can be applied around cutover, but the initial baseline does not have to stop the business from publishing throughout the entire migration. 

That baseline is not merely a page count. It is a structured inventory in which every relevant page, content entry, asset, URL, and relationship is classified by: 

• · Source type and destination content type. Record whether the item is a blog article, product record, resource, landing page, gated asset, reusable component, taxonomy term, or another content object, and identify the Contentful content type or Contentstack content type to which it will map.
• · Required fields and relationships. Capture headings, body fields, metadata, images, alt text, internal links, embedded media, calls to action, references, taxonomies, and other values that must survive the transformation.
• · Locale state. Treat each required language or market version as a separate validation item, while distinguishing genuinely localised values from values inherited through a fallback locale.
• · Asset and integration dependencies. Record dependencies on a DAM, search index, form platform, commerce system, personalisation service, analytics implementation, or external data source.
• · URL and traffic significance. Identify the current URL, proposed destination, redirect requirement, inbound traffic, backlinks, and business-critical entry points.
• · Editorial and technical ownership. Assign the person responsible for confirming that the migrated item is complete, correctly structured, and usable in its intended experience. 

This inventory becomes the reconciliation benchmark for the migration. Preserve the original timestamped snapshot rather than continually overwriting it, and record newly discovered content or subsequent source changes as controlled deltas. This distinction matters: the original baseline shows what was known at the start, while the delta log explains how the scope evolved. Much of the work is inventory hygiene – resolving duplicates, documenting previously unknown content, recording approved retirements, and ensuring that each source item has a traceable destination or disposition. 

Scope estimates can move in either direction as the inventory becomes more accurate. In one enterprise migration from Tridion to Contentstack, an early estimate of approximately 40,000 potential items was reduced substantially after duplicates, obsolete records, and non-migration candidates were classified. The final launch inventory contained approximately 14,000 locale-specific pages across 10 languages. The lesson is not the particular number; it is that an initial crawl count, an audited migration scope, and a final launch inventory measure different things. Without a controlled inventory and documented inclusion rules, those figures cannot be meaningfully compared.

The line-by-line reset: why most “missing pages” are an audit-freshness problem

Here is a pattern that appears frequently in large migrations and is especially important to understand when interpreting a late-stage gap report. 

Two or three weeks before launch, someone runs a gap report: everything in the baseline that does not yet have a match in the new platform. The number comes back alarming, thousands of pages that look unmigrated. Panic starts. Someone suggests slipping the date.

The team then reviews every flagged line against the latest migration and disposition records rather than relying on an audit snapshot created months earlier. In the Tridion-to-Contentstack example, a late-stage gap report initially suggested that a substantial number of pages remained unresolved. After line-by-line review, approximately 286 items still required migration or publishing, 238 required business review, and 741 had already been addressed through approved redirects but remained incorrectly classified as missing content. The updated analysis showed that the raw report overstated the remaining work because it combined genuine gaps with review items and completed redirect decisions. With those categories separated and the remaining items assigned, the launch date could be assessed against the actual risk rather than the headline count. 

This is the core insight: a late-stage “missing pages” report does not, by itself, prove that the content was lost or omitted. The report is only as reliable as the baseline, matching rules, migration status, redirect data, and publishing records behind it. When those sources are out of sync, the report creates false positives – items that have been migrated, redirected, consolidated, or intentionally retired but still appear as unresolved. Genuine migration gaps may remain, which is precisely why every flagged item needs an explicit disposition rather than being accepted at face value. 

The reconciliation method that survives this is boring and disciplined:

1. Give every flagged item a written disposition. Use statuses such as migrated and validated, migrated but unpublished, migration required, business review required, intentionally retired, consolidated into another item, or covered by an approved redirect. No item should remain unexplained.
2. Refresh the underlying data before generating each gap report. Reconcile the source inventory, destination entries, publishing state, locale state, redirect map, and approved scope changes so the comparison reflects the current migration rather than a previous snapshot.
3. Treat the disposition log as a launch artifact. “Nothing material was lost” should not remain a verbal assurance. It should be supported by a record in which every in-scope item has a status, destination or redirect, validation result, owner, and any required sign-off.

That log is what turns a claim into evidence. It is also what lets you defend the launch date when someone panics over a raw gap count.

URL and redirect parity: the second audit no one budgets for

Content reconciliation proves the content survived. It says nothing about whether the addresses survived. That is a separate deliverable, and it is where SEO equity and customer bookmarks quietly die.

For large enterprise migrations, the safest pattern is usually to execute legacy redirects at the CDN, edge, reverse-proxy, or another routing layer that does not depend on the new CMS successfully resolving content. If the redirect map is handled only after a request reaches application or CMS routing, URL preservation shares the same failure path as the platform being stabilised during cutover. Services such as Cloudflare Bulk Redirects and Akamai Edge Redirector can evaluate redirects before the request reaches the origin, reducing that dependency. The exact implementation may vary, but the requirement is consistent: legacy URLs should continue to resolve even if the new content-delivery path is temporarily unhealthy. 

Two more things separate a real redirect audit from a checkbox:

• Validate the redirect map against real request data, not only a sitemap. A sitemap primarily covers URLs the organisation currently knows and chooses to expose. CDN logs, server access logs, analytics landing-page data, backlink exports, search-console data, campaign records, and existing redirect rules reveal additional deep links and historical URLs that users and search engines still request. No single source is complete, so the audit should combine them. 
• Treat already-resolved redirects as done, not missing. This is the same freshness discipline as content. Those 741 already-redirected URLs above were reconciliation wins miscounted as failures. A log that doesn’t separate “no content and no redirect” from “intentionally redirected” scares everyone for no reason.

Reconciliation is a workstream, not a launch-week task

The reason some teams can prove nothing was lost and others cannot has little to do with talent or tooling. It comes down to when the work started.

Done well, reconciliation is scoped in discovery as its own workstream, running in parallel with migration scripting, front-end build, and integration validation. It has a named owner. It produces a living disposition log from week one. By launch, the log is being closed out, not built.

Done badly, it is a QA pass someone schedules for the final sprint, run against a baseline that was never frozen, comparing a fresh platform to a stale audit. That version proves nothing. It generates a panic, forces a fire drill, and either slips the date or ships with unverified gaps.

The cutover discipline that protects the reconciliation is worth naming, because it keeps the baseline valid through go-live:

• A content freeze on critical items in the window around cutover, so the source stops moving while you close the final comparison. On one fixed-date enterprise launch, a 24-hour freeze on critical content, with publishing halted in lower environments, kept the final reconciliation stable.
• A repeatable, scripted promotion process, so the content models, migration transformations, application build, configuration changes, and approved content release tested before cutover are the same versioned changes promoted into production. 
• A predefined rollback or roll-forward window tied to measurable acceptance criteria, with the previous production state, deployment artefacts, redirect configuration, and recovery procedure kept available until the cutover has passed its agreed validation checks. 
• A structured post-launch hypercare period, with its duration and severity framework defined according to the estate’s scale, traffic, localisation footprint, publishing cadence, and business risk. This captures issues that synthetic checks and pre-launch reviewers may miss but real users encounter after launch. 

None of this is exotic. It is the difference between a migration you can vouch for and one you are hoping went fine.

Not every migration requires the same level of ceremony. A 300-page marketing site with a simple content model, few integrations, limited localisation, and a modest URL history may be reconciled through an automated full-inventory comparison, targeted field checks by template, redirect validation, and deeper manual review of its highest-risk pages. It does not need the governance overhead of a complex multinational estate. The method should scale with the risk: interconnected content, high locale counts, regulated assets, complex integrations, significant organic traffic, and revenue-critical URLs justify more detailed evidence and approval controls.

What to ask a migration partner before you sign

Reconciliation is the workstream most likely to be invisible in a SOW and most likely to hurt you if it’s thin. Before you sign, ask the uncomfortable questions:

• “Show me the reconciliation schema and disposition log you will maintain through launch.” A credible answer should explain how source items map to destination content types, fields, references, assets, locales, publishing states, URLs, redirects, owners, and validation results. If the answer is simply “we run QA before go-live,” reconciliation is probably being treated as an assumption rather than a defined workstream. 
• “Where are legacy redirects executed, and what happens if the CMS or application origin is unavailable?” For a large estate, a strong answer will usually place redirects at the CDN, edge, proxy, or another routing layer independent of CMS content resolution, then describe how the map is validated against request logs, analytics, backlink data, search data, and known legacy rules. A CMS-only answer is not automatically wrong, but the partner should be able to explain its resilience, scale limits, deployment process, and failure behaviour. 
• “When a gap report shows thousands of missing pages two weeks out, what’s your process?” You want to hear “line-by-line disposition against a re-synced audit,” not “we’ll add resources.”
• “Who owns reconciliation, and from what week?” A named owner from discovery beats “the QA team” every time.

No responsible partner can promise a migration with zero surprises. What a serious partner can provide is traceability: a defined baseline, documented transformations, explicit dispositions, named owners, repeatable validation, and a process for investigating exceptions. That turns “did we lose anything?” from an anxious, open-ended question into a set of records that can be queried and tested. Reconciliation does not guarantee the absence of defects; it gives the team defensible evidence of what happened to every known in-scope item and a controlled way to resolve anything discovered later.

Frequently Asked Questions

How do you prove nothing was lost in a CMS migration?

You create defensible evidence by reconciling the destination against a timestamped source baseline and its subsequent change log. Every in-scope page, entry, asset, locale variant, relationship, URL, and redirect should receive a documented disposition and validation result. The disposition log does not prove that the original inventory was perfect, but it demonstrates what happened to every known item and makes unresolved exceptions visible before launch. 

What is the difference between content parity and redirect parity?

Content parity validates that required content and structure survived the transformation, including fields, metadata, references, images, alt text, internal links, embedded media, calls to action, localisation state, and publishing state. Redirect parity validates that legacy URLs still resolve to an approved destination with the intended status code and without unnecessary chains or loops. They are related but separate controls: content may be complete in the new CMS while important historical URLs still return errors or point to the wrong destination. 

Why can a late-stage gap report overstate the number of missing pages?

Gap reports frequently combine several different conditions: genuinely unmigrated content, unpublished entries, unmatched locale variants, records awaiting review, approved retirements, consolidated pages, and URLs already handled through redirects. They can also rely on stale source or destination data. The correct response is not to dismiss the report, but to refresh its inputs and assign every flagged item an explicit disposition. Only then can the team distinguish genuine migration work from reporting noise.

eight25 runs enterprise migrations from platforms such as Sitecore, AEM, and Tridion into Contentful and Contentstack, using structured content mapping, scripted transformation, locale-aware validation, and content-and-redirect reconciliation as defined workstreams from discovery. If your team is comparing migration approaches, we can show you the reconciliation structure we use to connect each source item to its destination content type, publishing state, locale, URL, redirect, validation result, and owner before a launch date is committed.