Website Redesign: How Do You Map Old Content Fields to New Page Modules Without Losing Information?

When mapping content fields for a website redesign, first explain what each old field represents, then decide which new module it belongs in, how to convert it and which relationships must be preserved. Identical field names do not guarantee identical meanings. A page that looks complete does not prove the admin system can still edit it correctly. A suitable approach is to trial the migration with representative content, confirm both display and edit-and-save results, then extend it to other records.

This article concerns the conversion of content structures. Old URL destinations and redirects still require separate planning. Use the website redesign migration checklist alongside this work so that migrated content remains reachable from its original entry points.

Understand old fields through one complete record

Choose an old record containing a title, body content, images, attachments and related categories, and compare its admin view with the public page. Do not discuss the new version using field names alone: a field called “summary” might appear on listing cards or be used only for admin searches. A “category” may determine navigation as well as a filter.

For each field, record the entity it describes, its actual purpose, whether empty values are allowed, whether multiple values are supported and where it appears. For images and attachments, also record order, explanatory text, applicable entities and source locations. Categories and related products are relationship data. Keeping only a display name while discarding the association is insufficient.

Business staff confirm meaning, editors explain daily use, and implementers check how the system saves the data. Register discrepancies before proceeding when their answers differ. For example, if editors have been adding specifications to body content while developers assume specifications come from separate fields, the migration rules must account for the actual content in both places.

Success means: the next participant can use the record to explain why a field exists and where it is used, without inferring its business meaning from page styling.

Write rules for placing content in the new modules

Consider a hypothetical product page: its old body content contains an application introduction, a specifications section and precautions, while the new design separates these into three modules. Do not split it automatically based only on paragraph length. Have the product information owner confirm each section’s purpose first, then agree what needs manual organization and what can be converted using a stable structure.

Each mapping must explain at least four things: where the old content comes from, where the new content goes, the basis for conversion and how exceptions are handled. When an old summary becomes a new listing summary, check field length and display scope. When body images move into a gallery, preserve their confirmed order and descriptions. When attachments move into a download module, retain their association with the correct product and version.

If the old system has multiple categories but the new one allows only one primary category, decide how to choose it and where the other relationships go. Do not let the system select the first item in the old list automatically. For empty old values, distinguish “not supplied,” “not applicable” and “not migrated in this round.” Do not fill them all with zero, default selections or promotional copy.

Contentful’s migration example converts text, images and references separately and first establishes a sandbox environment. It highlights a key issue: formats and relationships require separate handling. Each project should still design its rules around its own CMS, fields and editing tasks.

Trial the migration with samples likely to expose errors

After ordinary records migrate successfully, choose samples that could reveal gaps in the rules: records without summaries, with multiple attachments, with identical category names referring to different entities, with images embedded in body content, and with historical aliases retained in old materials. Rather than sampling randomly just to increase the count, first cover differences that affect the mapping outcome.

Write the expected result for each sample before running it. Attachment order should remain intact, for example; historical aliases should appear in their agreed location; unspecified values must not become confirmed specifications. After implementation, inspect the actual content against these expectations instead of relying only on the number of successful imports reported by the tool.

If body content is truncated, images enter the wrong modules or relationships point to the wrong entities, first establish whether the input materials are unclear, the conversion rules are insufficient or the implementation failed to follow them. After making corrections, rerun affected samples and confirm that this will not create duplicate entities or overwrite content edited later. Do not repeatedly experiment on the entire live database before the rules are stable.

Keep the old and new record identifiers and exception notes so each record can be traced. If old information has no place in the new structure yet, ask its owner to decide how to retain it. Do not silently discard it because the design has no corresponding box.

After checking the page, edit and save the content again

First ask someone outside the implementation team to identify the product, read the required information and find the correct attachments on the new page. Then enter the admin system, change an item agreed to be editable, save and reopen it, and check whether the fields, order and relationships remain intact. Return to the public page to confirm the corresponding change.

This reveals problems that appear only after an edit, even though the initial migration looked correct. Multiple attachments might be saved as a single item, separate sections from the old structure might merge, or a field with no admin location might be assembled temporarily on the public page. Implementers need to identify the cause, but the buyer should include this edit-and-save task in content acceptance.

If the new field structure cannot support routine updates, revisit choosing a CMS around editing tasks to check the solution, rather than treating a one-off migration patch as a long-term maintenance approach.

Mapping is complete when: the adopted rules have an identifiable version, old and new records correspond, public pages and the admin system use the same meanings, attachment identities are correct, and exceptions have decisions. The content owner confirms facts and relationships, implementers confirm conversion results, and editors confirm continued maintainability. A single page screenshot cannot substitute for all three confirmations.

Frequently asked questions

Is putting all old body content into the new rich-text field the safest approach?

It depends on future tasks. If specifications, categories or attachments need independent filtering and updates, merging everything into body content weakens those capabilities. Keep the original content for comparison while converting the necessary fields under confirmed rules.

If the new field is shorter, can we simply truncate the old summary?

First distinguish truncation for display from truncation during saving. The former preserves the original information; the latter may change it. Have the content owner approve any shortening so the system does not remove necessary conditions.

Does an unchanged record count prove no content was lost?

Counts check only part of the scope. Field values, attachment files, category relationships and edit-and-save behavior must be checked separately. Matching counts with incorrect relationships still do not mean the migration is complete.