Product Catalogue Migration: How to Scope the Work and Budget

A product catalogue migration is often described as an import task: export records from the old platform, load them into the new one, then publish. That description misses the work that usually determines effort and risk. The real scope depends on source-data quality, the target catalogue structure, the amount of editorial judgement required, and the checks needed before customers can use the new site.

For business owners, marketing leads, and project managers, product count is only one input. The more useful question is: what must be transferred, transformed, reviewed, created, excluded, and approved for each product type? A good scope makes those decisions explicit, separating predictable bulk operations from work that requires a person to interpret product information.

Why catalogue migration estimates differ

Two businesses may each have 1,000 products and still receive very different migration scopes. One catalogue may have reliable SKUs, complete attributes, consistent categories, correctly named image files, and a clean export. The other may combine a legacy CMS, spreadsheets, supplier documents, image folders, and descriptions written to different standards.

Record volume does not reveal whether products are duplicated, whether colour and size entries should become variants, whether measurements use mixed units, or whether the images actually belong to the named products. These are data and editorial decisions, not merely technical import steps.

A catalogue estimate also goes beyond redirects and preserving existing search visibility. Those matters can be part of a website launch, but catalogue work additionally covers product-level judgement: assigning structured attributes, resolving conflicting facts, matching media, rebuilding bundles, and deciding which obsolete records should not reach the new site.

Ask suppliers to distinguish automated transfer, rule-based transformation, review by exception, and manual work per item. A single vague “data migration” line makes it difficult to assess what changes if the source data proves less reliable than expected.

Create a catalogue inventory before requesting a quote

Start with the materials that actually exist, rather than an idealised view of the current website. The completed inventory below is illustrative only. It shows the detail needed for a reviewable estimate; replace its findings with the results of your own audit.

This inventory is not administrative overhead. It turns hidden work into visible decisions. For example, “images included” could mean copying files, linking files to products, choosing a primary image, cropping images, replacing poor-quality assets, or writing alternative text. Those are different tasks and should not be assumed to be the same deliverable.

Agree the target data model before the full import

The aim is not to reproduce every weakness of the old catalogue on a new platform. Before a complete product data import is prepared, agree the target model: product types, category hierarchy, attributes, brands, variant relationships, filters, statuses, and the handling of out-of-stock or retired items.

Product card templates shape the content workload

A product card is a content model expressed through an interface. If the target card includes a technical summary, specifications, downloads, a delivery note, compatibility details, and related products, the project needs a source and rule for each element. A field that can be empty in one category may leave an awkward gap or misleading hierarchy in another.

This is why website design development should be coordinated with catalogue scoping. Representative product and category layouts expose long titles, missing attributes, unsuitable image proportions, and situations where one universal card template is not practical. Design decisions are more dependable when they are tested against approved data, not placeholder content alone.

Categories, attributes, and variants need separate rules

Categories help people browse. Attributes help them compare and filter. Variants represent selectable versions of one product. A source system may blur these concepts by keeping them in free-text descriptions or separate rows, but the new catalogue needs defined rules if filters and product cards are to behave consistently.

• Use a stable unique identifier for every product and variant.
• Define controlled values for items such as brand, material, finish, or capacity.
• Set rules for parent products, child variants, bundles, replacements, and accessories.
• Identify fields that are mandatory only for particular product categories.
• Decide which legacy categories are mapped, merged, renamed, or retired.

Separate automated work from manual data work

Automation is valuable when source values are dependable and a repeatable rule exists. It can import identifiers, prices, stock values, known unit formats, and categories from an approved mapping. It is less dependable where values are inconsistent or the correct result depends on commercial or editorial meaning.

Manual work commonly includes matching ambiguous images, resolving duplicates, selecting a primary category, restructuring variants, checking product claims, completing mandatory fields, and rewriting inconsistent descriptions. The scope should say whether this work applies to every record, only to records that fail an agreed rule, or to a defined priority group.

A practical working plan uses three labels: automated for repeatable operations, review by exception for records that fail a rule, and manual per item for product-specific judgement. This prevents a bulk import from being mistaken for publication-ready catalogue content.

What belongs in a website content migration budget

Migration is only one component of a website project, but it should be scoped as a distinct workstream rather than treated as an unspecified inclusion in the build. For the wider factors that affect website creation cost, consider platform configuration, integrations, design, and ongoing requirements alongside the catalogue work.

When comparing proposals, check whether the following factors are included and what assumptions apply:

1. Discovery and audit: reviewing exports, file stores, legacy pages, supplier materials, and known exceptions.
2. Target configuration: setting up fields, taxonomy, product types, variants, filters, import rules, and relevant integrations.
3. Data preparation: mapping, normalisation, deduplication, formatting, media matching, and content transformation.
4. Content completion: writing or editing descriptions, validating specifications, preparing metadata, and supplying documents or category copy where required.
5. Import and remediation: trial runs, full import, error handling, correction cycles, and repeat imports where agreed.
6. Quality assurance: checking product facts, front-end cards, search, filters, media, links, and mobile presentation.
7. Governance and handover: decision-making, approvals, change control, documentation, and training for catalogue maintainers.

Volume matters, but it must be considered with complexity. A small range of configurable products with many technical properties can require more manual attention than a larger catalogue with a clean, standardised data feed. If the catalogue is multilingual, scope each language and field type separately: translating a title is a different task from validating technical specifications or adapting long-form product content.

Use a scope brief and acceptance checklist

A short written brief can prevent expensive ambiguity. A clear catalogue migration scope records the agreed inclusions, exclusions, rules, responsibilities, and assumptions so that a proposal can be compared fairly and changes can be assessed consistently.

Complete the following points before supplier discussions so that assumptions can be challenged early.

1. Business objective: define the priority, such as cleaner data, stronger filtering, a new commerce platform, a feed for a mobile app, or easier catalogue maintenance.
2. In-scope records: list active products, variants, categories, brands, documents, images, and content pages; identify what is explicitly excluded.
3. Source of truth: name the approved source for prices, stock, specifications, descriptions, media, and product status.
4. Target rules: document mandatory fields, taxonomy, attribute dictionaries, naming conventions, variant rules, and image requirements.
5. Publication standard: define what “ready to publish” means for each product type, including required text, images, metadata, and documents.
6. Exception policy: state how missing images, conflicts, duplicates, unmapped categories, and incomplete records are handled.
7. Representative sample: include simple products, variants, long descriptions, sparse records, and difficult media matches.
8. Acceptance checks: specify count reconciliation, completeness checks, visual review, filter testing, selected price checks, and named sign-off.

An acceptance criterion should be observable. “The import works” cannot be tested consistently. A better criterion is that approved active SKUs are present once, required fields follow the agreed rules, and selected samples show the correct price, images, category, variant, and filter values. Known exceptions should have an agreed treatment rather than becoming a surprise during launch review.

Run a pilot and review the customer experience

A pilot import tests more than file compatibility. It reveals whether field mapping, media rules, category logic, and card templates work with real product information. Select products that expose complexity, including variants, multiple images, dense specifications, incomplete source records, and materially different category structures.

Review the pilot in both the administration area and the public-facing interface. Data can look acceptable in a spreadsheet while producing an empty filter, an incorrectly cropped image, an unclear variant selector, or a card that hides an important specification. Where possible, turn a correction into a rule change; fixing a mapping rule can prevent the same problem across many records.

Control changes and prepare for handover

Stakeholders often request new fields or content improvements after seeing imported products. That is normal, but the project needs to distinguish a defect from a scope change. Failure to apply an agreed mapping rule is a defect. Adding comparison fields, rewriting every description, introducing another language, or changing the taxonomy after approval is additional work that can affect the budget and delivery plan.

Assign owners for product facts, brand terminology, pricing, stock, legal or compliance statements where relevant, and publication approval. A delivery team can implement agreed rules, but it should not be expected to invent commercial facts or approve product claims. At handover, the business should have the agreed import process or format, field definitions, naming rules, an exception list, and a practical process for future catalogue updates.

Choose the right clean-up level for launch

Not every catalogue requires a complete editorial overhaul before a new site goes live. Prioritise records by commercial importance, customer risk, traffic value, and data quality. Important products may receive full enrichment and review, while low-priority or discontinued records follow a simplified route or remain out of scope until their business value is confirmed.

A phased approach can control the initial website content migration budget when the first phase has stable identifiers, coherent categories, usable product cards, and a documented backlog. The avoidable risk is an undefined middle ground where every record is assumed to be included and polished despite incomplete data and no agreed approval process. Confirm the inventory, manual-work boundaries, target model, pilot criteria, correction rules, and sign-off responsibilities before approving the migration scope.