Website Data Migration Testing: Verify Records, Relationships and Media Before Launch

A new website can display the expected number of products and still contain the wrong catalogue. Two records may have been duplicated while two others disappeared. A brochure may open from the old server during testing, then fail when that server closes. A course can retain its title but lose the relationship that places it under the right subject.

To test a website data migration, compare a dated source with the destination using stable record identifiers, agreed field mappings and explicit exception rules. Reconcile totals by content type and status, verify relationships and files, inspect representative records, and rehearse late changes and repeat imports before accepting the result. A successful import message is one piece of evidence, not the acceptance decision.

This guide is for Indian business owners and project teams replacing a CMS, rebuilding a catalogue or moving ecommerce content in 2026. It focuses on whether the transferred data still means the right thing. Redirects and search visibility need their own workstream; everyday editing and supplier ownership need separate checks too. The examples below are fictional exercises, not WSC client results.

Define the migration boundary before exporting

Start with a content register: pages, articles, products, variations, categories, authors, downloadable documents and any custom record types. Identify which system supplies the authoritative version of each. A spreadsheet maintained by sales may contain current specifications while the website contains obsolete values. Resolve that disagreement before asking the migration team to preserve everything.

Record inclusions and exclusions explicitly. Published articles might move while abandoned drafts stay behind. Historical orders may require a separate supported process. A private customer area may contain personal information that should never enter a broadly accessible development copy. Agree appropriate handling with the people responsible for that information, and use sanitised fixtures wherever practical.

Put these decisions into the website design brief. State the source, destination, responsible owner, migration window and evidence expected for each content group. The brief should distinguish a transfer defect from an intentional editorial decision. Removing an expired promotion deliberately is different from losing it accidentally.

Freeze a reference version

Give the source export a timestamp and a meaningful version label. Preserve the export, mapping specification and transformation rules together in a protected project location. Ask the developer to record the extraction method and any filters. Without that baseline, a difference discovered later may be impossible to classify: import failure, source edit or intentional change.

Agree whether the source remains editable during development. Most businesses cannot stop publishing for weeks. If editing continues, maintain a change log and plan how additions, updates and deletions reach the destination. A content freeze can be short, but it must be explicit. The final copy should not depend on someone remembering which pages changed last Friday.

Agree identifiers and field mappings

A title is usually a poor record identifier. Titles change, several products may share a name, and two articles can legitimately have similar headings. Ask for a stable source key and a retained source-to-destination mapping. That mapping makes it possible to investigate a particular record and determine whether a second import updated it or created another copy.

Destination database numbers do not necessarily match source numbers. For example, the WooCommerce CSV documentation explains that new products receive available IDs rather than a chosen imported post ID. The practical lesson is to verify the supported matching mechanism instead of requiring identical internal numbers across different systems.

Write transformation rules before reviewing results

For each important field, record the source name, destination name, data type, transformation and expected treatment of blank values. A missing specification might mean unknown, not zero. An empty imported field might preserve an existing destination value or clear it, depending on the tool and configuration. Test the actual behaviour selected for the project.

Include formatting rules. Preserve leading zeroes in identifiers that are text. Check punctuation, line breaks, accented names and relevant Indian-language text. Verify decimal values and units separately: a stored number of 12 does not tell a buyer whether the product is 12 millimetres or 12 centimetres. Dates also need a defined timezone and display expectation.

Choose transformations that can be explained to the business owner. Combining separate address lines into one field may be acceptable; discarding an address component silently is not. If rich text becomes a different editor format, identify how headings, lists, links and embedded media will be represented. Keep the rules versioned so a later correction can be traced to a specific import run.

Reconcile counts without mistaking totals for accuracy

Count records by useful groups, not only as one grand total. Compare products separately from variants, articles separately from pages, and published records separately from drafts or archived material. Then reconcile included source records against imported records, intentional exclusions and unresolved failures. Every difference needs a reason that can be traced to an identifier.

Suppose a fictional export contains 120 product records. The agreed plan excludes eight discontinued items, leaving 112 expected destination records. If the destination contains 112, the count passes, but identity still needs checking. One omitted item and one duplicate produce the same total. Compare the expected identifier set with the actual mapped set to find both problems.

Keep a readable exception register

An import warning should become a reviewable issue rather than disappear into a developer's terminal history. Record the source identifier, affected field or relationship, failure reason, proposed action, owner and retest state. Distinguish records rejected entirely from records imported with a missing optional field. Those outcomes have different business consequences.

Ask for an explicit treatment of intentional exclusions. They should not be hidden under a generic failed count. Similarly, an unexplained difference should not be relabelled as an exclusion merely to make the numbers reconcile. The register is useful precisely because it separates agreed decisions from implementation failures and leaves unresolved questions visible.

Verify relationships and publication states

Relationships give records their business meaning. A product belongs to categories; a variation belongs to a parent product; an article has an author; a document belongs to a particular service or model. Seeing all those records individually does not prove the connections survived. Test the source relationship against its mapped destination, including the direction of the connection.

Use deliberate edge cases. Select a product in two categories, a category nested under another category, a page with several related resources and a record whose parent was excluded. Ask what should happen to that orphaned relationship. The correct outcome may be reassignment, rejection or omission, but it should be agreed rather than left to a default.

Check what becomes public

Inspect draft, private, scheduled and published examples. A migrated draft becoming publicly available is a substantive failure even when its text transfers perfectly. Likewise, a published page accidentally becoming a draft can disappear from navigation and discovery. Confirm scheduled timestamps against the destination timezone rather than relying only on a familiar date displayed in an export.

WordPress describes its WXR export as containing several content and taxonomy types. That format description helps define the transfer boundary; it does not prove a particular destination imports every custom behaviour. Consult the supported import route and check the installed extensions and record types involved.

Follow the transferred relationships through the public interface as well as the administrator. A correctly stored category may still be absent from a template query. A brochure relationship may exist while its download button points elsewhere. Open the representative category, record and related resource together, and distinguish a data problem from a rendering or navigation problem.

Test media independently of text records

Build a file manifest for required images and documents. Record the source reference, destination location, owning content record and expected accessibility. A destination page can appear complete because its HTML still loads an image from the old domain. Check the actual requested host and path, not simply whether a photograph appears during the demonstration.

Confirm that files are available through the intended supported mechanism. Some migrations copy binaries; others fetch remote files during import; some preserve only references. Ask what happens when the old host becomes unavailable. Where practical, have the technical team demonstrate the destination without relying on the source system, in a controlled test that does not interrupt production.

Verify integrity and presentation separately

For files that should remain unchanged, a checksum comparison can establish byte-for-byte equality. If images are resized or converted intentionally, equality is not the right expectation. Check the agreed dimensions, visual quality, orientation, crop and file association instead. Open representative PDFs and confirm their content rather than assuming a successful HTTP response means the right brochure arrived.

Check captions, alt text and download labels where they are part of scope. Select examples with multiple images and with similarly named documents to expose accidental reassociation. A file named brochure-final.pdf is not a reliable identity rule across a large archive. Use stable references and verify which document each public page actually offers.

Keep private files out of public media tests. The destination must preserve the agreed access boundary, not merely reproduce an old path. Use non-sensitive fixtures to demonstrate restricted retrieval. A public 200 response is appropriate for an approved brochure but may reveal a serious mistake for a document intended only for authorised users.

Rehearse late changes and repeat imports

Run a representative transfer in an isolated destination before the final cutover. Shopify's product import guidance recommends backing up product data and describes important overwrite considerations. Review the applicable tool's behaviour before testing. Do not assume a general undo button exists or that interrupting an import restores the previous state.

During the rehearsal, add one fictional source record, update another and mark a third for agreed removal. Run the planned delta process and check all three outcomes. Determine how the migration identifies changes: timestamps, explicit lists, a fresh export or another supported method. Ask how it handles a record edited on both systems after the first transfer.

Prove that rerunning does not create duplicates

Repeat the same controlled input and inspect identifiers, record counts and relationships. A safe rerun should behave according to the documented design. If the tool is intended only for one-time creation, the plan needs a clean reset or another controlled recovery method. Do not discover that limitation while trying to repair a partial production import.

Test a failure boundary too. A missing required field or unavailable media file should produce an understandable result. Establish whether other records continue, which changes persist and how the failed subset is retried. Keep the evidence scoped to the tested behaviour; a small rehearsal does not certify every possible load, interruption or concurrency condition.

Run a fictional catalogue exercise

Imagine a Delhi training supplier moving a small course catalogue to a new CMS. It has course descriptions, subject categories and downloadable outlines. The business agrees that withdrawn courses stay out, published courses remain public and unpublished drafts remain private. This example tests transferred content and relationships; it does not claim actual migration performance.

Choose a published course with two categories and two documents. Record its source key, publication state, title, duration, category keys and document references. Add a second course with an empty optional field and a third containing Hindi text. Have the destination owner predict the expected records from the mapping specification before looking at the imported output.

After import, reconcile the identifier sets and inspect the chosen records. One outline loads successfully, but the network request points to the old host. Another course appears twice because its edited title was used as the matching key. These are different defects: media dependency and record identity. Give each its own correction and rerun evidence.

Finally, update a course description in the source and rerun the planned change process. Check that the existing destination record changes, its relationships remain correct and no second copy appears. The business reviewer then checks meaning and presentation while the developer retains the technical reconciliation. Both forms of evidence contribute to acceptance.

Decide what evidence supports acceptance

Combine automated reconciliation with human review. Where feasible, automated checks should cover all included identifiers, required fields, relationship references and expected file availability. Manual inspection should use a deliberate sample of difficult cases and business-critical records. Record the sample selection so nobody mistakes a handful of attractive pages for a complete audit.

Agree severity before the final meeting. Missing required records, exposed private content or broken critical documents can block acceptance. A minor formatting issue might be accepted conditionally with an owner and retest date. The decision depends on the actual scope and consequence; avoid declaring every cosmetic difference equally serious or silently accepting every warning.

Keep the evidence package concise: source version, mapping version, import run reference, reconciliation totals, exception register, sampled checks and outstanding decisions. Link it to the delivered release. WSC's CMS demonstration guide addresses daily editing; require those tasks separately after the migrated content is in place.

If URLs change, coordinate this work with the website redesign SEO checklist. Google's site-move documentation covers URL mapping and search migration. Correct transferred data does not establish correct redirects, and redirects do not establish correct transferred data. Give each workstream an accountable owner.

Choose a sample that can reveal the wrong assumptions

A random handful of records can miss the difficult structures entirely. Build a short sampling list around the ways your content varies: oldest and newest entries, long and short descriptions, multiple relationships, empty optional fields, unusual characters, and files added through different historical workflows. Include business-critical pages even if their structure is ordinary. Document why each example is in the sample.

Ask someone who understands the content to review meaning, not only formatting. A developer can confirm that a field arrived without knowing that its value describes a retired model. Conversely, a business reviewer may recognise the correct description while overlooking an unintended publication state. Assign these responsibilities explicitly so each reviewer knows what evidence they are providing.

For a catalogue, compare specifications against the approved baseline rather than memory. If the source contains known errors, list their corrections as transformations with owners. Otherwise the team cannot tell whether a changed value is an approved improvement or an import defect. Retain the old and new values in the exception record where that comparison is useful.

Keep private evidence proportionate. A redacted record reference and a precise issue description often explain a problem without copying customer information into a shared presentation. Store detailed exports only where authorised project staff can access them. The acceptance record needs enough detail to reproduce the check, not unrestricted distribution of the underlying data.

Finally, rerun the affected sample after fixes. If a mapping rule changed globally, ask the developer which additional records were affected and expand verification accordingly. Closing the visible example alone does not establish that the same transformation worked everywhere else. Record the rule version and final result alongside the original finding.

Avoid common website migration testing mistakes

• Accepting an import success banner. Inspect the records, exclusions and warnings behind it.
• Comparing only the grand total. Reconcile identities and meaningful subgroups to reveal offsetting losses and duplicates.
• Using titles as permanent keys. Confirm a supported stable matching rule before reruns.
• Checking text but ignoring relationships. Trace parents, categories, related resources and public states.
• Leaving source-host dependencies invisible. Verify where destination images and documents are actually served.
• Editing exports casually. Preserve originals and inspect the saved format after any intentional transformation.
• Forgetting changes made during development. Rehearse the delta process and define the final editing window.
• Signing off a stale rehearsal. Reconcile the final transfer and its exceptions against the agreed current baseline.

Use the migration sign-off checklist

• Source systems, content types, authoritative owners and exclusions are documented.
• A dated baseline and versioned field mapping are retained securely.
• Stable source keys map to destination records without unexplained duplicates.
• Counts reconcile by type and status, with every difference classified.
• Required fields, blank values, units, dates and relevant language text are checked.
• Parents, categories, related records and publication states match the agreed rules.
• Required files are present, correctly associated and independent of retired infrastructure.
• Private data stays within the agreed access boundary.
• Late changes, conflicts, failed subsets and repeat imports have been rehearsed.
• Final evidence identifies the release, open exceptions, owners and acceptance decision.

Accept a reconciled transfer, with clear limits

A website development scope for an online store should include its data transfer requirements. A proportionate migration review makes missing information and unresolved decisions visible before the old platform disappears. A small brochure site may need a short register and careful page checks; a large catalogue needs more systematic reconciliation. Neither benefits from an unexplained pass percentage or a promise that every future problem has been eliminated.

Agree what must survive, prove the mappings and rehearse the transition while corrections are still manageable. If you are commissioning a new platform, discuss your migration requirements with WSC, including sources, custom records and acceptance evidence. Confirm the proposed transfer scope before approving the launch.

Sources

• WordPress: Tools Export screen
• WordPress: Tools Import screen
• Shopify: importing products with a CSV file
• WooCommerce: product CSV importer and exporter
• Google Search Central: site moves with URL changes

Sources checked on 6 November 2026. Illustrative photography: fauxels and Jahra Tasfia Reza, used under the Pexels licence. Photographs do not depict WSC staff, client data or project outcomes.