Documentation Migration With a Hard Launch Date
Northwind Analytics sells a B2B SaaS product and runs its help content on a twelve-year-old CMS. The site holds 1,850 articles, but the top 50 account for 70% of article pageviews and 42% of all organic landing sessions. Support tickets repeatedly cite "can't find the answer," and the site search log shows 300 queries per week returning zero results. The company has nine weeks before launch on a new CMS that stores content as structured topics rather than pages. Three writers are available, one part-time SEO specialist, and no dedicated developer after week six. An accessibility audit sampled 300 articles and found missing alt text, skipped heading levels, and tables used for layout. Legal requires that retired content remain retrievable for twelve months but not publicly visible. The VP of Support wants every article migrated; the VP of Marketing wants the launch date protected.
1. Define the migration scope you would recommend and justify what gets migrated, consolidated, or retired.
Read the worked answer
Recommendation: migrate roughly 400 articles, consolidate about 250, and archive the rest. Start from evidence rather than the article count. Pull twelve months of pageview and organic-entry data, join it to ticket tags and zero-result search queries, and score each article on traffic, support value, and uniqueness. Migrate the top 300 by sessions plus every article referenced by a ticket macro or a top-20 zero-result query. Merge near-duplicates into structured topics with anchored sections; the new CMS rewards this and it reduces the accessibility surface. Retire articles with no sessions, no inbound links, and no legal hold.
Why this is defensible: migrating 1,850 articles in nine weeks with three writers guarantees template-level defects and stale content, and the VP of Support's "everything" request is not a priority model. Publish the scoring method and the retired list for review so the decision is auditable and reversible. Keep legal-retained articles in a non-public archive with a documented retrieval path, and confirm with legal that an internal archive satisfies the twelve-month requirement.
2. Design the URL and redirect approach, including how to handle articles merged into a single topic and articles retired for legal reasons.
Read the worked answer
Use a one-to-one 301 for every migrated article, preserving the old slug where it still describes the content. For consolidated topics, 301 each source URL to the specific topic, not to the topic index or the home page; a blanket redirect to home creates soft 404s and wastes accumulated link equity. For retired articles with no legal need, return 410 after a short 301 grace period if analytics show residual traffic. For legal-retained articles, remove them from public navigation and return 404 or 410 publicly while keeping the internal archive; do not leave them indexable.
Build the redirect map as a CSV in version control with columns for source, target, status, and owner. Test it with a crawler against the old URL inventory, then monitor server-log 404s and Search Console coverage for ninety days. Normalize trailing slashes and case, update internal links and sitemaps, and avoid 302s for permanent moves. The reasoning is that redirects are a product surface, not a one-time script; they need testing, ownership, and a rollback copy.
3. Recommend a governance model that keeps the new knowledge base from decaying after launch.
Read the worked answer
Name a content owner for each product area and make that ownership visible in the CMS. Define a "done" checklist that includes accessibility checks (alt text, heading order, real table markup), metadata, and a review date. Fix accessibility at the template and component level first, then remediate the highest-traffic articles; do not hand-fix 300 articles when the template causes most defects.
Operate a monthly editorial board that reviews zero-result searches, ticket deflection, stale-content reports, and redirect errors. Give writers a deprecation workflow: mark, redirect, archive, and delete after the legal window. Measure the system with leading indicators-zero-result rate, percentage of articles past review date, accessibility defects per template-not just pageviews. Tie vendor or agency content work to the same checklist. The reasoning is that migration is a project, but content decay is a process; without named owners and a review cadence, the new CMS will reproduce the old site's problems within a year.