As a corporate website ages, its underlying system often struggles to keep up with the business. An older Chinese CMS used years ago may no longer be maintained and may suffer repeated security vulnerabilities, for example, or the team may decide to rebuild a traditional template-based site with a modern, decoupled frontend and backend to improve loading speeds overseas.

But while “changing the engine”—replacing the CMS or technology stack—it is easy to trigger an incident that drives marketing and sales teams up the wall: The new website looks attractive when it launches, but a week later, sales suddenly discovers that all the PDF specification download links on an old product page are broken. Marketing finds that image paths in older articles now produce broken images. The colleague running paid campaigns discovers that Baidu Analytics and Google Ads conversion tracking code was left out during the system change, leaving an entire week of advertising data in the dark.

To make a cross-system architectural rebuild watertight, the technical migration standards at JVDS never allow developers to rely on ad hoc manual copying and pasting. The following 4 engineering inventory steps must be completed:

Map UI

1. Before Starting Work: Crawl the Old Website to Build a “Complete Asset Inventory”

Often, even the client cannot remember exactly how many hidden campaign pages and attachments the old website contains. Before writing new code, scan the entire old website with a professional site crawler such as Screaming Frog and export a complete asset inventory:

  • Every HTML page URL returning 200 OK, together with its <title>, <meta description>, and <H1>;
  • All static resource paths across the site, especially product brochure PDFs, CAD drawings, and compressed driver packages under /upload/ or /downloads/. Many clients who outsource their websites print QR codes linking directly to these PDFs in their brochures. If the paths change, the codes in tens of thousands of printed brochures become dead links!
  • All third-party scripts attached to page headers and footers, including GA4, Baidu Analytics, GTM, live chat, and CRM form webhook endpoints.

Redirect

2. Database Migration: Map Fields and “Clean Up Paths in Rich-Text Content”

The old and new CMSs will inevitably have different database table structures. When writing a migration script, the area requiring the most care is rich-text body content (Rich Text HTML) in articles and product details:

  • Many legacy systems hard-code absolute paths in their content, such as <img src="http://old-test-ip/uploads/2022/1.jpg">, or use outdated inline styles such as style="font-family: SimSun; font-size: 12px".
  • Before inserting data into the database, the migration script must run a regular-expression cleanup: replace all image and attachment links with consistent CDN or relative paths for the new site, strip out unwanted inline styles that disrupt its layout, and retain only the clean semantic tags <p>, <h2>, <ul>, and <table>.

Editing

3. Preserve URL Routes: Keep Existing Paths Wherever Possible and Add 301 Redirects for Every Necessary Change

This is vital to retaining Baidu and Google rankings. If an article on the old site uses the path /share/website-design/123.html, the new system can continue supporting that address through rewrite rules. If paths genuinely need to change to English slugs for more meaningful URLs, use the asset inventory exported in step one to configure strict one-to-one 301 permanent redirect rules at the Nginx layer. Include mappings for old PDF download paths printed in physical brochures as well.

4. Before Switching DNS: Run an “Automated Regression Comparison” Between Staging and Production

After importing the data into the staging environment, crawl that environment too and cross-check it against the old site’s inventory. Verify that the total page counts match, that images and attachments do not return 404 errors, that each core page’s title, description, and keywords (TDK) have been fully preserved, and that the CRM receives data correctly after form submission. Only once every check is green should you smoothly switch DNS during an overnight period of low traffic.