Designing a Content Migration Without Losing Meaning

Treat migration as editorial change, not transport

A page can arrive in a new content management system with every sentence intact and still lose meaning. Its heading hierarchy may flatten. A caption may become detached from its image. An update date may be mistaken for an original publication date. A policy may survive after the service it governed has changed. A useful old URL may point to the homepage. Search filters may lose the metadata that made the item discoverable. The bytes moved; the content did not survive as a dependable part of the service.

The better starting question is not "How do we copy everything?" It is "What must remain true after the move?" That usually includes the user's purpose, the organisation's reason for publishing, the relationships between content items, the authority behind a claim, the state of the record, the route by which people find it, and the person responsible for its next review. E2W's web and software systems work therefore treats content, templates, redirects, search, metadata, and governance as one migration system.

A content migration is complete when meaning, evidence, relationships, and ownership survive the move—not when every source row has been imported.

Gate 1: inventory meaning, not just URLs

Begin with a defensible source inventory: crawlable URLs, files, media, structured records, forms, taxonomies, navigation labels, redirects, canonical annotations, language variants, access restrictions, analytics identifiers, and content that exists outside the public sitemap. Add what a crawler cannot infer: business owner, intended audience, user task, legal or records status, source evidence, sensitivity, review date, downstream reuse, and known replacement. Preserve the source identifier even when the destination URL will change.

A count of pages is useful for estimating volume, not value. Two pages may look duplicate while serving different audiences or evidentiary roles; ten campaign pages may be safely consolidated into one current service page. E2W's professional interpretation is to give every source item a decision state—retain, revise, combine, redirect, archive, restrict, or delete—and to record the reason, decision owner, destination, dependencies, and evidence. That turns an export into an editorial ledger.

Gate 2: map the content model before mapping fields

A legacy field called "body" may contain headings, tables, callouts, embedded media, contact details, and dates with different meanings. Copying that field into another rich-text box preserves formatting debt. First define the destination concepts: article, service, person, location, policy, project, document, event, or reusable guidance block. Then define each type's purpose, required fields, relationships, validation rules, ownership, version behavior, and retirement path.

The field map should distinguish mechanical conversion from editorial interpretation. A known date format can be transformed automatically; deciding whether a date means published, effective, reviewed, or expired requires evidence. NARA's transfer guidance is specific to U.S. federal records, yet its principle is useful beyond that setting: documentation and metadata are needed so transferred electronic records can be identified, serviced, and interpreted over time [1]. The commercial lesson is not to copy a government schema. It is to move the context required to understand and operate the content.

Gate 3: preserve structure and accessibility semantics

Visual similarity is not structural equivalence. During conversion, retain the relationships expressed by headings, lists, tables, labels, links, quotations, captions, language, and text alternatives. WCAG 2.2 requires information and relationships conveyed through presentation to be programmatically determinable or available in text, and requires text alternatives for non-text content [2]. W3C's guidance also explains that descriptive headings help people understand and navigate the organisation of a page [3].

Create explicit transformation rules for every supported source pattern. Reject or quarantine patterns that cannot be converted safely instead of silently flattening them. Review alt text in context: an image may be decorative in one page and essential evidence in another. Re-test keyboard operation, focus order, form labels, error messages, tables, embedded media, document downloads, and responsive reading order in the rendered destination. Accessibility is not an attribute that can be copied once; it is an outcome of content, markup, component behavior, and publishing practice.

Gate 4: make each URL decision explicit

Build a one-row-per-source-URL map before launch. Record the final destination, decision type, redirect status, canonical target, language equivalent, query-parameter treatment, inbound importance, and test result. Google recommends preparing an accurate old-to-new URL mapping, updating internal links and annotations, using server-side permanent redirects where possible, avoiding irrelevant redirects, and monitoring both old and new URLs during a move [4]. RFC 9110 defines 301 and 308 as permanent redirection responses, with 308 explicitly preserving the request method [5]. The correct status still depends on the route and application behavior.

Do not send every removed page to the homepage. A redirect should lead to a genuinely equivalent or consolidated destination. If no useful replacement exists, a clear not-found or retired-content outcome may be more honest. Preserve fragments where relevant, update canonical and hreflang annotations, regenerate sitemaps, replace internal links, and test chains and loops. Keep the mapping as an operated record after launch because external links, bookmarks, integrations, and crawlers will continue to reveal missed routes.

Gate 5: separate publication, withdrawal, archive, and deletion

Migration is a rare opportunity to remove content that is wrong, redundant, unsupported, or no longer needed—but deletion should not be the default response to uncertainty. Define distinct lifecycle states. Published content is current and findable. Withdrawn content may remain available with an explanation. Archived content is preserved for evidence or history but is not presented as current guidance. Restricted content remains controlled. Deleted content has passed the organisation's legal, privacy, records, and operational checks.

GOV.UK's publishing guidance distinguishes withdrawal, where content remains at the same URL with a notice, from unpublishing, which removes it and can redirect users to current content [6]. That is one platform's policy, not a universal rule, but it demonstrates why "not current" and "must disappear" are different decisions. Where preservation matters, PREMIS models digital preservation around objects, events, rights, agents, and intellectual entities, and defines migration as a transformation intended to minimise loss of content, formatting, and functionality [7]. Use the retention model appropriate to the organisation and jurisdiction; do not invent it inside the migration spreadsheet.

Gate 6: keep provenance and structured evidence attached

For content that makes consequential claims, preserve the source, author or responsible team, approval state, original publication date, revision history, effective period, jurisdiction, related policy, and reason for change. For assets, retain rights, licence, credit, consent, description, original file, derivative relationship, and replacement history where applicable. For structured records, move the schema or data dictionary required to interpret the fields—not only the exported values.

Public structured data is another evidence layer. Google recommends complete and accurate properties over a larger set of incomplete or inaccurate markup, and recommends testing structured data during development and monitoring it after deployment [8]. Migration acceptance should therefore compare what the new page visibly says with its canonical URL, metadata, social previews, structured data, feeds, APIs, search index, and any channel that reuses the record. One authoritative value should not emerge as six conflicting copies.

Gate 7: rehearse with representative and difficult content

A perfect demonstration page proves very little. Build a rehearsal set that covers high-traffic services, long-form guidance, tables, forms, galleries, multilingual pages, PDFs, historic records, restricted items, expired campaigns, duplicate topics, unusual embeds, deeply linked resources, and the oldest supported markup. Include content owned by different teams and items with unresolved decisions. These are where the migration model reveals whether it can represent the real estate rather than the clean sample.

Run automated checks for counts, missing fields, malformed links, redirect coverage, duplicate titles, orphan pages, status codes, canonical mismatches, inaccessible assets, schema validity, and checksums where file integrity matters. Pair them with human review of meaning, tone, hierarchy, accessibility, factual currency, and user task completion. W3C's accessibility-management guidance recommends clear responsibilities, early and regular evaluation, issue tracking, monitoring, and user feedback [9]. Treat those as continuing controls, not a one-day compliance sweep.

Gate 8: use the E2W content migration acceptance record

E2W's professional interpretation is to accept migration through eight connected gates: inventory, content model, semantics, URLs, lifecycle, evidence, rehearsal, and operational ownership. For each gate, record its scope, owner, rule set, automated evidence, human sample, exceptions, severity, due date, and release decision. Rate it accepted, accepted with a bounded condition, or held. A good average cannot offset a missing legal record, broken priority journey, inaccessible form, or unmapped high-value URL.

The final record should identify the source and destination releases, export and import versions, item counts by decision state, approved variances, unresolved risks, redirect and archive owners, monitoring window, rollback or correction route, and the people authorised to accept the result. It should also say when the legacy system can be made read-only and when it may be decommissioned. That decision should follow verified transfer, retention, security, and recovery requirements—not the licence renewal date alone.

Ask these questions before cutover

Can every high-value source item be traced to a destination or an approved lifecycle decision? Can editors explain what each destination field means and who maintains it? Are dates, authorship, evidence, rights, language, and review state preserved accurately? Do headings, links, images, tables, forms, and downloads retain their purpose for people using assistive technology? Does every changed URL have an appropriate tested outcome? Can search, navigation, metadata, structured data, and downstream integrations find the new record? Can the organisation prove what was archived or deleted and why?

If the answer depends on opening the old CMS after launch, the migration is not yet complete. Keep the legacy source available in a controlled form until reconciliation, exceptions, and acceptance are finished. A successful migration is not the moment the import script stops. It is the point at which users can still find and trust the right meaning, editors can govern it, and the organisation can explain every consequential transformation.