Audit event-site content before moving to a new CMS

Define the move and the publication boundary

Write down the old CMS, the proposed CMS, the exact event site, the current edition and the person authorized to approve event facts. Confirm whether the domain, URL paths, ticket provider and media host will stay the same. Mark each as unchanged, changing or unknown. A CMS replacement can be scoped to content while DNS, checkout and email remain with their existing owners. If another project changes those systems too, give it a separate plan and owner so one checklist does not hide several cutovers.

Set a content snapshot time and a change log. Between the export and launch, an organizer may correct a venue entrance, open sales, add a speaker or change a session time. Record each live edit with its source and approver, then decide how it will reach the new CMS. A frozen export with no delta log can make the preview look complete while the published site silently reverts a late correction. Reserve an explicit date for the owner to review the final content inventory and sign off on unresolved items.

Inventory pages, assets and relationships

Build one row per public URL and one row per CMS record that feeds several pages. Include the series hub, current event page, edition pages, agenda and sessions, speakers, venue and travel information, FAQ, sponsor and exhibitor pages, post-event recaps, downloadable files and localized variants that actually exist. Include pages hidden from the main menu if attendees can reach them from an email, QR code or search result. Do not assume the CMS export is the whole site: compare it with the live navigation, sitemap, event emails and an agreed sample of analytics or server records if available.

For each row, capture old URL, page purpose, event edition, locale, public/private state, current owner, last approved update, source record ID, template, attached media and outgoing action links. Note relationships, not just titles: which speaker belongs to which session; which program belongs to which day; which venue directions refer to which entrance. A file library can contain old poster versions with the same filename, so record the file's public use and approved revision separately. The worksheet makes exceptions visible before a bulk import is attempted.

Decide what carries forward

Give each item a content decision: copy after verification, revise from an approved source, retain as a dated archive, combine with a genuinely equivalent page, or retire with an owner-approved destination. Do not use low traffic alone to delete a page. A parking instruction or accessible-arrival note may answer an important visitor question even if it receives few visits; a previous year's recap may be useful as an archive but wrong for this year's checkout path. Check the current event facts against the program, venue and ticket owners rather than trusting an old CMS field as the source of truth.

Record the next action and decision owner beside every exception. If a session title is approved but its room is still undecided, mark that field unapproved instead of carrying over last year's room. If an old sponsor page is being retired, check every page that links to it before choosing a replacement. Keep the current edition and historical editions distinct; an archive should retain its own dates and context. The audit is complete only when unanswered decisions are either resolved or explicitly excluded from launch.

Map the old content model into the new one

Create a second sheet for content types and fields, not just page URLs. For each old type, record its purpose and the new type or field that will hold it. List the data format, required status, locale behavior, relationship and transformation rule. A date-time stored as one free-text string may need separate date, time and time-zone fields; a session speaker stored as plain text may become a linked speaker record. Those are editorial decisions as well as technical mappings. Preserve the approved display wording and time zone instead of inferring them from a database export.

Try the mapping with representative records before bulk import: one simple current event, one multi-day program, one localized page, one postponed or archived edition and one page with unusual media or download links. Document what the new CMS cannot represent without a custom field, component or manual edit. If the old site publishes Event structured data, include its date, location, status and ticket-link values in the comparison with visible page facts; Google documents these as properties of event markup, not as a feature every CMS supplies automatically. Do not mark a record mapped merely because its title imported.[2]

Map visitor URLs and external handoffs separately

Keep existing public paths when they still serve the same page and can be preserved. If a path must change, list the old URL, intended new URL and reason before launch. Google advises mapping old URLs to corresponding destinations, updating internal links and using redirects for actual URL moves. A generic redirect to the home page is not a substitute for a relevant event answer. Keep campaign links, QR codes, published speaker links and archived-edition URLs in the review, because people may still use them after the CMS changes.

Separate content managed by the CMS from an external action. A ticket button may point to a provider checkout; a map, form, calendar link or livestream may depend on another account. Record its owner, exact destination, access setting and fallback without claiming the migration will copy it. Carry over image and download locations if they change, and check the pages that refer to those files. For multilingual pages, map each locale to its own intended destination rather than redirecting every translation to a single language. The content team approves the destination; the technical owner implements and tests URL behavior.[1]

Preview real attendee paths before release

Build a review set from the inventory, not only the home page. Open one path that starts from search or an old bookmark, one from an invitation, one from the event series page and one from a phone-sized viewport. Check the current edition's date, time zone, venue, admission terms and next action against approved records. Follow the ticket link as far as the public handoff without submitting an order. Check that past-event pages do not silently lead to the current checkout unless the page clearly explains the change.

Compare a sample of each page type and locale with the old site and approved source. Check headings, readable tables, images, captions, downloads, mobile layout, keyboard navigation and links. W3C advises text alternatives according to an image's purpose, so a copied file without its useful alt text needs review. If Event structured data existed, verify that its facts still match the visible event page and use the appropriate validator; importing a script does not prove its values are current. Record each defect with page URL, expected fact, observed result, owner and retest status.[3][2]

Reconcile the import and publish with an owner

Before switching the public site, compare source and destination counts by page type, edition and locale. Counts are only a completeness signal: one missing high-value venue page matters more than several harmless draft records. Walk through every unresolved exception and the late-edit log. Have the event fact owner approve the public content, the CMS owner approve field mapping and the website owner approve links and publication state. Save the inventory version used for that decision so the team can explain what launched.

After launch, open the mapped URLs from a clean browser session. Confirm the intended current page, archive, downloads and external handoffs, and inspect broken links or unexpected errors. For changed URLs, review redirects, internal links, sitemap and Search Console evidence over time; Google notes a site move is processed per URL rather than on a guaranteed date. If a critical fact or action is wrong, use the documented rollback or correction owner and record the exact affected URLs. Keep the audit as an operating record for the next edition instead of treating the migration as the end of content maintenance.[1]

Download the CMS content audit and field-mapping worksheet (Markdown, English)