The CMS that "just needs a bit of training"

A municipal communications team I spoke with described their CMS situation like this: "We've been meaning to fix the publishing workflow for three years. We just keep telling new staff it's complicated, but you get used to it."

They had 12 people who could theoretically update the site. Three of them actually did. The other nine had given up.

That's not a training problem. That's a liability.

A CMS is infrastructure. When it's working well, your team publishes faster, content stays consistent, and editors feel confident. When it's not, everything slows down, mistakes multiply, and the site quietly starts to reflect the friction behind it.

The challenge is knowing when you've crossed from "frustrating but manageable" into "this is costing us more than a migration would."

Six signs your CMS has become a liability

1. Publishing requires a developer

If a communications coordinator can't update a service page without submitting a ticket, your CMS is a bottleneck, not a tool. Content management systems exist so that non-technical staff can own their content. When every change needs developer time, you're paying engineering rates for editorial work.

2. You've outgrown the content model

Every CMS ships with assumptions about content structure. When your content complexity has grown past those assumptions (say, you need structured event data, multilingual fields, or complex permission hierarchies and your platform treats everything as a generic "page"), you compensate with workarounds. Those workarounds accumulate until every editor is navigating a system held together by convention and institutional memory.

3. Security updates are overdue or impossible

Outdated CMS versions carry real risk. If you're running a platform that no longer receives security patches, or if your team has delayed updates because the last one broke the site, you have an active liability issue. Ontario public sector organizations face specific obligations under cybersecurity frameworks, and "we meant to update it" is not a defensible posture after an incident.

4. The vendor or community is winding down

Open-source CMS platforms live and die by their contributor communities. Hosted platforms live and die by their business models. If your platform's community forums are quiet, the roadmap is stale, or the company behind it has been acquired twice, start paying attention. Migrating on your own timeline is far less painful than migrating under pressure after support ends.

5. Your editors route around the system

When staff email PDFs instead of updating web pages, maintain shadow spreadsheets of "what the site actually says," or paste content into a Google Doc before going anywhere near the CMS, the system has failed them. The workarounds feel minor until you audit the site and find content that hasn't been updated in four years because nobody wanted to deal with the publishing interface.

6. Performance or accessibility complaints are structural

Some performance problems are fixable. If your CMS generates bloated HTML by design, forces full-page rebuilds on every edit, or outputs image-heavy layouts with no lazy-loading support, a plugin isn't going to fix it. Same with accessibility: if the editing interface produces non-semantic markup and there's no way to override it, you're carrying technical debt directly into your WCAG compliance posture.

If two or more of these apply to your situation, a migration is worth serious consideration.

The pre-migration audit: before you touch anything

The biggest migration mistakes happen before a single page moves. Teams get excited about the new platform and skip the unglamorous work of understanding what they actually have.

Here's what to audit before you evaluate anything new.

Inventory your content

Pull a full sitemap export, not just the top-level navigation. Document:

You're looking for three categories: content to migrate as-is, content to consolidate or rewrite, and content to archive or delete. Most organizations discover that 30-40% of their content is either outdated, duplicated, or not worth migrating. That's a gift. Don't migrate garbage into a clean system.

Map your content types

List every distinct type of content your site publishes: service pages, news items, staff profiles, downloadable documents, event listings, and anything else. For each type, note the fields it uses and whether those fields are structured or free-text.

This becomes your content model specification for the new platform. If your current CMS has been treating everything as a generic page with a WYSIWYG body, this audit will reveal how much structure you've actually been managing manually.

Document your integrations

What does your current CMS talk to? Common integrations to map include:

Every integration is a migration task. Know what you have before you scope the project.

Identify your hardest content

Every site has content that's going to be painful to migrate: deeply nested page structures, landing pages with custom layouts, interactive tools, or content with complex permission rules. Surface these early. They're the reason migrations take longer than planned.

Evaluating new platforms

The right CMS for your organization is the one your team will actually use consistently. Evaluate platforms against these criteria, not just feature lists.

Editor experience: Can your non-technical staff publish and update content confidently, without documentation? Ask vendors for an unscripted demo where an editor creates, edits, and previews a page.

Content model flexibility: Can the platform support the content types you documented in your audit? Does it separate content from presentation in a way that survives redesigns?

Hosting and infrastructure options: Does it run on infrastructure your organization can actually procure? Some Ontario public sector clients have specific requirements around data residency or vendor contracts that narrow the field.

Accessibility of the editing interface: The CMS itself must be accessible to editors who use assistive technology. This is often overlooked and worth testing explicitly, not just reading about in documentation.

Migration path and tooling: Does the platform have documented import tools? Is there an active ecosystem of migration specialists? A platform with great features but no available migration support adds project risk.

Total cost of ownership: Licensing or hosting fees are only part of the picture. Factor in training time, ongoing developer costs for customization and maintenance, and what happens if you need to leave in five years.

Evaluate at least three platforms. The first one you look at will seem transformative because you're comparing it to a broken incumbent.

Mapping redirects and preserving SEO equity

Redirect mapping is almost always underscoped. It's also where migrations lose the most value.

Every URL on your current site that has inbound links, indexed search results, or embedded references in other documents is a redirect liability if it changes. This includes:

The standard approach is to build a redirect spreadsheet with three columns: old URL, new URL, and redirect type (301 for permanent). Start with your highest-traffic pages (from your analytics audit) and work down.

Tools like Screaming Frog, Sitebulb, or a manual crawl can generate a full URL list. Pair that with your analytics export to prioritize.

A note on 404s: don't redirect everything to the homepage as a fallback. A blanket homepage redirect signals to search engines that your redirects aren't meaningful, and it delivers a bad experience to users who followed a real link. Map real destinations or use a proper 404 page with helpful navigation.

Running a parallel testing period

Before you cut over, run both systems simultaneously for a defined period. This is standard practice and still frequently skipped.

A parallel testing period means:

Define explicit pass/fail criteria before you start. "The site looks good" is not a criterion. Acceptable criteria include: all 301 redirects return correct status codes, all migrated pages render without layout errors, Lighthouse accessibility score is 90 or above, form submissions route correctly, and editors can complete the five most common publishing tasks without assistance.

Schedule the cutover during a low-traffic period, typically Tuesday to Thursday mid-morning is safer than a Friday afternoon. Keep the old environment accessible (even if not publicly indexed) for at least 30 days post-launch.

Seven failure points to avoid

Most CMS migrations fail in predictable ways. Here's where to pay attention.

1. Skipping the content audit. Migrating without auditing means moving stale, duplicate, or low-quality content into a system you're paying to maintain. Do the audit.

2. Underscoping redirect work. Redirect mapping is scoped as "a few hours" and routinely runs to weeks. Treat it as a project phase, not a task.

3. Migrating to a CMS that solves today's problems but not tomorrow's. If you're outgrowing one platform, choose a successor that has room to grow. Migrating to a similarly limited system because it's cheaper up front is how organizations end up migrating again in three years.

4. No editor training before launch. If editors encounter the new system for the first time at launch, they'll revert to workarounds. Run structured training sessions during the parallel period, while the stakes are low.

5. Cutting over before the redirect map is complete. A partial redirect map is as bad as no redirect map. Set a launch gate: 100% of in-scope redirects must be tested before cutover.

6. Treating migration as a one-time project instead of a process. The first month post-launch will surface issues your parallel testing missed. Budget for a three to six month stabilization period with clear ownership.

7. No documented rollback plan. If something critical breaks after cutover, what happens? Who makes the call, and what are the steps? Have this written down before you flip the switch.

A pre-migration readiness checklist

Use this before committing to a migration timeline.

If you can check all twelve boxes, you're ready to scope a migration. If six or fewer are checked, you're not ready yet, and that's useful information.

A CMS migration is one of the highest-leverage investments a web team can make, and one of the easiest to get wrong at the planning stage. Get in touch if you'd like help auditing your current platform or scoping a migration that actually lands.