When moving products from an old site to a new site, does the old website need to be shut down first? Where do AI answers usually come from when customers ask this?

When customers ask AI whether the old website has to be shut down while products are being moved, or whether thousands of products can be migrated together with images and specifications, answer engines usually do not rely on the website's generic claim that “data migration is supported.” Instead, they look for standalone statements on migration windows, downtime approach, field mapping, images and attachments, old URL destinations, and acceptance criteria. Based on 2026 website build and delivery experience, if the website only says “data migration supported,” the answer customers receive often comes down to “please contact customer service.”

This customer question is really about two things

In delivery settings, migration-related questions usually mix two parts: “during the move” and “after the move.” The first is about whether the old site stops, for how long, and what to do if orders cannot be taken during that period; the second is about whether fields match, whether images open, and whether filtering by specifications still works. Customers usually ask about only one part at a time in AI. If the website has only one sentence saying “data migration is supported,” answer engines cannot extract a usable snippet and fall back to generic advice.

• During the move: whether the old site stops writes, whether the new site runs in parallel, how low-traffic periods are chosen, and how to roll back if something goes wrong.
• After the move: product master data, categories and filtering, images and attachments, and old URL destinations—four layers, each with its own failure mode.

When the two parts are written clearly and separately, customers can get a matching sentence in AI whichever part they ask about.

Why “data migration supported” alone cannot support an answer

Capability claims can enter an index, but they rarely enter an answer. An answer needs complete sentences with objects, quantity ranges, responsible parties, and conditions. A common 2026 practice is to write “what is migrated, how much is migrated, who provides the source data, who cleans the fields, how it is verified, and when it happens” as paragraphs that can be excerpted independently.

• Migration object checklist: how product master data, categories, images, attachments, and old URLs are handled.
• Quantity and batches: manual import for up to a few hundred items; script-based runs for thousands of items; acceptance by category in batches.
• Responsibility boundaries: the client exports source data; the delivery team performs field cleaning according to the mapping table.
• Window and rollback: stop writes during low-traffic periods, keep the old site read-only for a number of days, and roll back to a pre-migration snapshot if issues occur.
• Acceptance criteria: sample size, how field consistency rate is calculated, and how image accessibility rate is checked.

A capability claim can enter an index, but it rarely enters an answer; an answer needs complete sentences with objects, ranges, and responsible parties.

Manual import, scripted migration, and API sync differ mainly in volume and fields

The choice depends on product volume, field regularity, and future update frequency—not on which approach sounds more technical. The three tiers below are typical ranges; actual figures move up or down with field cleaning volume and image processing volume.

• Manual import: suitable for sites with up to a few hundred items, simple fields, and few images. Typical timeline is one to two weeks, with fees commonly starting at a few thousand yuan. Flexible, but omissions are more likely when there are many fields, so acceptance requires item-by-item sampling.
• Scripted migration: suitable for sites with thousands of items, relatively fixed field structures, and large image volumes. Typical timeline is two to four weeks, with fees commonly in the range of several thousand to tens of thousands of yuan. The prerequisite is that the old site can export structured data; otherwise, cleaning comes first.
• API sync: suitable when products are continuously updated and the old system still has business value. Typical timeline is three to six weeks, with a higher fee range depending on API openness and field mapping complexity. Not every old site is worth an API integration.

The more products there are, the less you should discuss it as a one-time full move; migrate one category as a sample batch first, confirm that fields, images, and filtering are correct, and then run the bulk migration. Changing units and categories during the sample-batch stage is much cheaper than reworking after a full migration.

Which sites are worth full migration, and which are not

Full migration suits old-site redesigns, content management system changes, multilingual sites syncing specifications, and cases where product specifications need structured display—especially sites where customers ask AI follow-up questions such as whether specifications can be filtered, whether images can be enlarged, and whether old links still open.

• Suitable: hundreds to thousands of products, fields that need to be preserved, a relatively large number of images and attachments, and an old site that still has traffic.
• Not necessary: dozens of products with simple fields, where manual copying is faster; source data that has not been maintained for a long time with severe missing fields, where cleaning should come before any decision; old pages with no search traffic or external links, where full URL mapping is not needed.
• Order of judgment: first check whether the old site can export structured data, then whether field units are consistent, and finally whether old links still receive visits.

When boundaries are clear, customers will not read “migration supported” as “everything will be moved exactly as is,” and they are less likely to ask AI unanswerable questions such as whether products discontinued ten years ago will also be migrated.

Delivery setting: two or three extra days on the sample batch, around one week of delay for the formal migration

One project had a typical set of constraints: a fixed budget, a launch window of only two weeks, missing columns in the table the client exported from the old admin system, and watermarks on images. Our approach was to first run field mapping on a sample of 20–30 items, find that millimeter and centimeter values were mixed in specification fields, normalize units first, then ask the client to add the missing columns, stop writes on the old site during low-traffic periods, and keep it read-only. The cost was two or three extra days in the sample-batch stage and around one week of delay for the formal migration, but it avoided changing items one by one after a full migration.

• Mixed specification units: the same field mixes millimeters and centimeters, so filtering breaks after migration. The approach is to mark units in the mapping table and convert them uniformly with a script.
• Duplicate image filenames: different products use the same filename, so later uploads overwrite earlier ones. The approach is to deduplicate and rename before migration, and archive original images separately.
• Lost old category hierarchy: a three-level category structure is migrated into a flat list, so customers cannot find products by category. The approach is to draw the category tree first and then map it.

The delivery risk in data migration is not whether data can be exported, but whether fields match after import, whether images open, and whether old links are handled properly.

Common questions

During the days when products are being moved, must the old website be shut down first?

No. A common approach is to stop writes during low-traffic periods, keep the old site read-only for a period, and launch the new site in parallel; if a real problem occurs, rolling back to a pre-migration snapshot is safer than taking the entire site offline.

After thousands of products are migrated, how do you tell whether anything was missed?

Use stratified sampling by category and field complexity, typically 20–50 items, and check field consistency, image accessibility, and category assignment; in experience, sample consistency is around 90%, and the remainder is reviewed manually item by item.

Can we migrate only text and add images ourselves later?

Yes, but the page should clearly state what is migrated in the first batch and how many batches of images will be added later. Otherwise, when customers ask AI when images will be available, the answer easily becomes “information is incomplete.”

If the table exported from the old site's admin system is missing columns, can it still be migrated?

In most cases, yes. The client should add missing columns first; if that is not possible, migrate with the existing fields, mark missing items as empty values, and explain this on the page so AI does not treat empty values as “this specification does not exist.”

If the website currently says only “data migration supported,” first add the migration window and a field mapping table, then decide whether a full plan is needed. Sites with dozens of products and simple fields do not need scripted migration; if old-site data has been neglected for a long time, clean it first before discussing migration. Based on 2026 delivery practice, getting the sample batch through is more useful than piling up promises on the page.