Changing CMS During a Redesign: Should Historical Inquiries, Attachments and Follow-Up Notes Be Migrated Together?

When changing CMS, not every historical inquiry needs to move into the new admin system. Assess migration for records still being followed up or frequently consulted. Materials used only for historical reference can be archived as read-only if access and maintenance conditions are met. Whichever approach is chosen, preserve the relationships between inquiries, attachments and notes, and have the business owner confirm retention scope and permissions.

Launching new pages does not mean old business records have been accommodated. List items for migration, archiving and further confirmation first, then plan cutover. Otherwise, the new admin system may receive new inquiries while sales staff cannot find files discussed earlier.

Choose destinations according to business use

Ask the people handling follow-up to select records in different states and explain what they still need to do. An inquiry requiring a reply or more information has different system needs from a closed record occasionally needed for reference. The former usually needs an owner, status and notes that support continued work; the latter may need only reliable search and reading access.

Do not group records by year alone. An older inquiry may still be under discussion, while a newer one may need no further handling. Also check whether the record already exists in a CRM or another business system. If there is a clearly designated master record, the website admin system may need only its source and association. Do not create another set of mutually updated copies without an agreed arrangement.

Use the website-to-CRM workflow arrangements to check how the current website passes new leads to sales. Where historical data belongs this time is a separate decision. Specify who needs to search it, what they need to find and whether editing is permitted.

Success at this step means: business staff can find items still requiring work from the inventory, historical reference has a defined location, and a designated role continues to confirm records with unresolved retention conditions.

Inventory records, attachments and notes separately

Inspect exported submission fields, identifiers, dates, source pages, owners, handling statuses and notes separately. Confirm that export filters cover the agreed scope. There should be reasons for excluding ordinary records, other statuses, specific dates or forms, rather than simply inheriting tool defaults.

For example, Gravity Forms’ export documentation allows selection of forms, fields, entry statuses and dates, with Active as the default status. This shows why downloading a CSV still requires checking the selected scope. Other CMS export options may differ, so inspect the actual result.

Attachments require an inventory of the files themselves and their record relationships. A URL in a spreadsheet is not an attachment backup. If notes are stored in another module or external system, their appearance on the original admin page does not mean they are included in the same export file.

List unavailable attachments, files without corresponding records and unclear statuses as exceptions. Do not replace historical files with current ones, making an old inquiry appear to concern today’s version.

Map old and new record identities

When importing into the new admin system, preserve the mapping between the old source, old record identifier and new identifier. It is common for a new system to assign new identifiers. Matching numbers or similar customer names cannot establish successful migration. Once record identity is confirmed, associate its attachments and notes.

Dates and statuses also need interpretation. Original submission time, latest follow-up time and this import’s time are different information. Do not replace every customer submission date with the import date. Business staff should confirm what an old “handled” status means in the new system so it is not misread as a completed sale or a request still awaiting a reply.

For notes, preserve available original times, authors or roles and content order. If old records lack this information, mark it as not supplied rather than adding a current owner to historical notes. If the new system already has similar records, check their business identity and differences before deciding how to link or merge them. Do not default to overwriting the entire row.

Migrate a small set of samples in a controlled environment first, and ask business staff to explain each record’s history and next step. Beyond readable fields, confirm that old-to-new correspondence can be traced. This mapping will support later gap-filling and retries.

An archive must also lead to the correct files

A read-only archive may be a controlled read-only interface to the retained old system or a separate searchable information package. Choose according to search, permission and maintenance requirements. A compressed package that requires the old account, old host and verbal explanations from former staff is not yet an archive that others can take over.

Beyond saving file locations, actually open an attachment from an inquiry and check its content and applicable version. GravityKit’s file migration guidance identifies a specific risk: if file retrieval fails, a record may still point to the old website, and its link will fail when that website closes. This product’s behavior does not represent every CMS, but it highlights the need to check actual file destinations during acceptance.

Inquiries and internal notes are not public website materials. Arrange archive entry points, file access and use of copies under permissions confirmed by the business. Include backups and test materials in the same handling scope. The website team should not invent a universal retention period; the responsible business role must confirm it.

Check scope on both sides of cutover

Agree on an identifiable cutoff point for the final migration. If the old website continues to receive inquiries, specify how records added after that point will be included and who checks them. Do not close the old entry immediately after the first export and overlook submissions made during the interval.

For acceptance, first compare counts for each object type with the exception inventory. Then inspect samples individually, including active inquiries, records with multiple attachments or extensive notes, and read-only archive entries. Have authorized users actually search, open attachments and confirm relationships. An administrator’s ability to open a file alone does not prove that business users can continue using it.

Retirement conditions for the old system should include usable migrated records, a searchable archive, files independent of locations scheduled for shutdown, handled new records and explicit decisions for unmigrated items. Use the content and functionality checks for changing CMS for the broader cutover, and retain historical inquiry acceptance separately.

Frequently asked questions

Does a read-only archive need no maintenance?

Someone still needs to manage access permissions, storage locations and file availability. Preventing edits does not mean accounts, hosting or storage can be left unmanaged.

Do different old and new identifiers mean the migration is wrong?

Not necessarily. Check the old-to-new mapping, key fields and attachment relationships. Changed identifiers may be part of a normal conversion; missing traceable correspondence is what obstructs verification.

Can the old host be shut down immediately after records are migrated?

First confirm that attachments and archive entry points work independently and that new records created during cutover were not missed. Resolve any remaining dependencies on the old website and retest before retiring it as agreed.