Migrate Apparel ERP Master Data Without Losing Style and Size Identity

An apparel ERP migration can balance perfectly and still send the wrong size to a customer. Suppose the old system holds 100 blue small shirts and 150 blue medium shirts. A bad mapping moves 30 pieces from medium to small. The combined total stays 250.

A grand-total check passes. The product identity check fails.

Master data migration must preserve what each code means. It must also preserve the links between that code, its stock, its open orders, and the people who use it.

This guide explains how to move apparel product data. It covers styles, colours, sizes, units, and the codes that link them. All examples are hypothetical. The focus is what the data means and how to check it before cutover. Each ERP needs its own supported import route.

Define what must survive the move

Start with the work. Can the team still identify the same product after the move? Can it buy, make, receive, sell, and return that product?

That requires more than a description. A style needs its variants. A variant needs valid units and codes. Open orders need to point to the right variant. Old labels may still be on physical stock.

Write the required outcomes for each data family. For product data, test order entry and barcode lookup. Check stock enquiry and a return against an old reference.

ApparelDiary's apparel ERP checklist provides the wider system context. The migration work here starts after the target's required behaviour is understood.

Keep finance and legal-retention decisions with their owners. The product-data team should not make those choices alone. Historical documents may serve needs outside its scope.

Separate style identity from variant identity

A style groups related products. A variant identifies a specific combination of product features. The business can buy, hold, or sell that variant.

In an apparel example, the combination may include style, colour, size, and fit. The actual target model may use different fields or names.

Microsoft Dynamics 365 defines product variants through product dimensions. Its documentation lists colour, configuration, size, style, and version as available dimensions. That is a product-specific model, not a universal list for every ERP. Product dimensions

Do not map a source “style” field by name alone. In one system it may mean a design family. In another, it may be one dimension beneath a product master.

Create a glossary with a source example, a target example, and the business meaning. Resolve those differences before loading thousands of rows.

Count valid combinations rather than every possible combination

Suppose style S100 has three colours and four sizes. The full mathematical grid contains twelve combinations.

Possible variants = Number of colours × Number of sizes.

Possible variants = 3 × 4 = 12.

The approved range may offer only nine. Perhaps one colour has a limited size run. The target should create the nine valid variants, not all twelve by default.

Keep a valid-combination table from an approved source. Compare the target's resulting set with that table.

A missing combination can block an open order. An invented combination may appear in a selling or planning screen. Nobody approved it, yet staff may start using it.

Microsoft's dimension documentation includes examples where only some colour–size combinations exist. Use the target's supported variant rules to preserve the intended range. Variant combinations

Build a crosswalk that explains every source code

A crosswalk links the old identity to the new one. Give it enough context to avoid accidental matches.

Treat source codes as text. “00073” and “73” may be different identifiers. Do not let a spreadsheet remove leading zeros before anyone reviews them.

Keep the original description to help with review. Similar wording alone must not decide the mapping. “Navy tee M” may describe several products.

An unresolved mapping should stop the affected records. It should not default to the nearest-looking variant.

Keep all identifier layers visible

One product may have several codes. It may have internal item and variant numbers. Supplier codes, buyer codes, and a barcode can add further links.

Preserve the relationships between those identifiers. Do not squeeze them into one text field separated by commas.

Microsoft explains that an item number alone may not identify a variant in Dynamics 365. The product dimensions can be needed as well. Its guidance also distinguishes product numbers from external identifiers. Product identifiers

For migration, test each important lookup route. Scan an old stock label. Enter a buyer's item code. Search the internal code used on a current purchase order.

Each should lead to the intended variant or to a clear, controlled exception. A successful import of the main product table does not prove that these routes work.

Preserve GTIN meaning during an internal renumbering

An internal ERP code and a Global Trade Item Number serve different roles. Changing the ERP does not by itself make the physical trade item a new product.

Map existing valid trade-item identifiers carefully. Do not generate a fresh barcode number merely because the target assigns a new internal key.

GS1's GTIN Management Standard, release 1.1, gives apparel examples. Each style, colour, and size variation has its own GTIN in those examples. The standard also distinguishes product introduction and product changes. GS1 GTIN Management Standard

Use that identification logic when checking the migrated associations. A specific product change needs its own GTIN review. This article does not decide that result.

Check packaging levels separately. A carton code should not resolve as though it were one retail piece. Preserve the quantity and trade-item meaning behind each code.

Decide which apparent duplicates are real aliases

Suppose eleven active source codes map to nine approved variants. Two source codes are old aliases for products that now have preferred codes.

That can be valid. Document the many-to-one mapping. Keep evidence that the codes represent the same product.

Do not merge two items just because their descriptions match. Check buyer ownership and the fabric specification. The fit block, season, or pack form may differ too.

An alias merge in the master table also does not prove that two stock rows are duplicates. The old codes may hold real quantities in different bins.

Preserve each stock row's location, lot, status, and ownership during the conversion. Before removing a stock record, check the evidence. Does it repeat the same physical balance?

Keep the old codes searchable after migration where the operating process needs them. Otherwise, staff may create the retired codes again.

Resolve codes that were reused over time

An old system may have reused an item code after a product left the range. A crosswalk keyed only by that code would then point two different products to one target.

Check the dates and source records before deciding that reuse is harmless. An old return can refer to the earlier product while a new order refers to the later one.

Where codes were reused, the mapping needs more context. That may be a source company, product version, season, or effective-date range. Choose the key from the evidence. Do not add season by habit if the same product legitimately carries across seasons.

Test one old document and one current document that share the reused code. Both should resolve to the intended identity. If an old case is unsupported, provide a clear lookup route for it.

This is also a reason to keep the untouched extract. A working spreadsheet may replace the old codes. After that, it can be hard to recover the evidence that set them apart.

Review inactive records through their dependencies

An inactive item may still have stock or an open order. A pending return or an old document may also need its identity.

Check those dependencies before placing the item outside the migration scope.

One proposed decision table is:

These are planning choices, not universal ERP capabilities.

Keep an exclusion register. Record the source code, reason, owner, and where its history will remain accessible. “Not migrated” should be a traceable decision.

Define unit conversions before moving balances

Units can corrupt a migration without changing the appearance of a number. Twenty cartons and twenty pieces are not the same stock.

Suppose one approved carton contains twelve pieces. There are twenty full cartons and thirty-five loose pieces.

Base pieces = Full cartons × Pieces per carton + Loose pieces.

Base pieces = 20 × 12 + 35 = 275 pieces.

The variables refer to this item and pack definition. Do not apply twelve pieces per carton to every product.

Microsoft's unit guidance covers conversion factors, unit classes, and decimal precision. Those settings affect how imported quantities are interpreted and rounded. Manage units of measure

Store the source unit and conversion evidence with the migration record. Test both the quantity and the unit shown in the target.

Do not invent a fixed conversion for variable material

Fabric may be purchased by mass and consumed by length. A general conversion between kilograms and metres may not fit every fabric or lot.

Use the source's approved basis for conversion. Do not choose a factor just because it makes the totals agree.

Where the target supports dual units, establish which quantity is measured and which is derived. Where it does not, decide how the business will retain the second quantity.

The same care applies to cones, rolls, bundles, and assortments. A container count does not always imply a fixed content quantity.

Keep rounding rules explicit. A small rounding difference repeated across many records can become material. Compare quantities at the required precision before applying display formatting.

If a conversion is unresolved, leave the affected balance in the exception queue. A guessed conversion can create a clean-looking but unusable stock position.

Profile the source before cleaning it

Profile a dated extract and keep it unchanged. Record row counts, unique keys, empty required fields, duplicate keys, and invalid references.

Check code lengths and unusual characters. Look for trailing spaces and mixed case. Check colour spellings. Ask whether size codes carry a meaning that is not obvious.

Do not automatically remove every difference. “M” in one size scale may not equal “M” in another. “Black” from two suppliers may refer to different approved shades.

Separate a harmless formatting cleanup from a business merge. The first changes how a known value is written. The second changes which records the system treats as one identity.

Keep the cleanup rules in a repeatable transformation. A person should not have to remember which rows were edited in a spreadsheet during the last trial.

Load through supported objects in dependency order

Find the target's supported import objects and their keys. Confirm whether each object creates, updates, releases, or merely links a product.

Dynamics 365 offers several product entities with different purposes. Its import guidance distinguishes shared products from products released to a legal entity. It also notes limits on the Released product creation V2 entity. Import product data

A load might start with dimensions and units, then product masters. Valid variants and company setup can follow. Load external identifiers next, then the transactions and balances that use them.

The exact sequence depends on the target. Microsoft documents, for example, that variant imports require dimension values to exist and released variants require shared variants. Product data entities

Use vendor-supported routes. A direct table insert can bypass business logic. Some links or derived settings may then be incomplete.

Keep staging errors as business work

A rejected row needs a source identity, a clear reason, an owner, and a route back into the next trial.

Do not delete failures from the input merely to produce a successful job status.

Group errors by cause. A missing colour code may block hundreds of variants. Fixing the reference table may resolve all of them. A single ambiguous old item needs a different kind of review.

Preserve the original value beside the proposed correction. That lets the data owner judge whether the change is sound.

After correction, rerun the affected load through the defined process. Confirm whether the target treats it as a new row or an update.

Maintain a reconciliation of attempted, accepted, rejected, and deliberately excluded records. Every source row should have an explained destination or status.

Reconcile the variant set before checking stock

Return to the nine valid S100 variants. Compare the expected and actual sets, not just their counts.

The counts may both be nine. One missing variant and one invented variant can still hide inside that match.

List expected variants absent from the target. Then list target variants absent from the approved range. Review both lists.

Check all eleven source aliases. Each active code must map to one approved target variant. A source code with two destinations is ambiguous. A target with several sources needs the approved alias explanation.

Store those results with the mapping version and extract time. A later crosswalk change should trigger another comparison.

This check is small enough to perform by hand on a pilot style. Use it to validate the automated logic before scaling up.

Work through a stock reconciliation

The hypothetical extract below has six valid stock rows. Two old codes refer to the same blue medium variant in different bins.

Total source stock = 100 + 120 + 30 + 80 + 200 + 170 = 700 pieces.

Blue medium totals 150 pieces across two bins. Its alias merge must retain both physical balances.

The expected target total is 700. The expected variant–bin set also has six rows under this example's grain.

If the target consolidates bins differently, the approved mapping must explain that change. Do not compare rows at different levels and call every difference an error.

Detect a balanced but wrong mapping

Now mis-map ALT002's thirty pieces to blue small. The target still holds 700 pieces in total.

The total difference is zero. The sum of absolute variant differences is sixty pieces.

Absolute variant difference = |30| + |−30| + |0| = 60 pieces.

That sixty is a diagnostic sum, not sixty missing physical garments. Thirty pieces were assigned to the wrong variant, affecting two comparison rows.

Use the detailed differences to find the mapping error. Correct the crosswalk and repeat the trial. Do not post an unexplained stock adjustment merely to make the new system appear right.

Handle an old code that hides several variants

A many-to-one alias merge is only one kind of mapping. The opposite case can be harder: one old code may cover several products that the new system must track separately.

Suppose the old code MIX holds 150 shirts in mixed small and medium sizes. The target needs a small code and a medium code. A total of 150 does not reveal how many belong to each.

Do not split the stock 75–75 because that is easy. A sales ratio is not proof of the physical size mix either.

A verified count might find 60 small and 90 medium shirts. Those counts support a 150-piece opening position in two variants. Keep the count record and its link to the old balance.

If the split cannot be established before cutover, define a controlled holding route. Do not publish guessed quantities as available stock in both sizes.

The same issue can affect old order history. When the source never recorded a detail, a crosswalk cannot recreate it with certainty. Preserve that limit in the historical view instead of inventing a precise size distribution.

Check open transactions through the new identities

An open sales order must still request the right colour and size after migration. An open purchase order must retain its unit, remaining quantity, and supplier item link.

Test a small set of meaningful transactions with the migrated master data. Try a partial receipt, a split size order, and a return. Test substituted or superseded codes where the business uses them.

Compare document lines, not only document totals. A value can balance while the size assortment is wrong.

Check whether the target supports the source transaction state. Some migration tools accept only certain open-document forms. Resolve unsupported states with the implementation team before cutover.

The master-data crosswalk should explain every product link in the transaction extract. A fallback “miscellaneous item” may keep the load running while destroying useful identity.

Test the workflow with warehouse and merchandising staff

Ask a warehouse user to scan a real-format old label in the test system. Ask a merchandiser to enter a buyer code and select a size run.

Have them describe what they expect before showing the result. That reduces the chance that they accept a plausible but wrong screen.

Check the printed and exported output too. A correct internal variant can still appear under the wrong buyer code on a packing list.

Use controlled test documents and prevent them from reaching live trading partners. The purpose is to prove the workflow, not create real duplicate orders.

Record the observed result against each test case. “Users checked the data” is too vague. Record a specific result: “Old code ALT002 opens S100-Blue-M and shows both expected bins.” Another person can review that evidence.

Rehearse the final change window

A trial load uses a dated snapshot. Work continues after that snapshot. The plan must control the resulting data changes.

Define who may create or edit master data during the final window. One option is to freeze edits for a period. Others are controlled double maintenance or reliable change capture. Choose a method the target can support.

Include edits and retirements, not only new rows. A colour-code correction made after the snapshot can matter as much as a newly created style.

Rehearse the final extract, mapping, load, and checks in the order the team will use. Measure the time with realistic data.

Do not promise zero downtime from a generic method. Check what the system can do and how busy the business will be. Allow time to collect the evidence needed before release.

Set a release decision with named evidence

The release record should identify the extract and mapping version. Add the import jobs, exception list, and reconciliation outputs.

Require unresolved material identity errors to be closed or explicitly handled before dependent work starts. A high overall success percentage does not make a wrong size mapping acceptable.

Name an owner for each check. Cover product identity, stock, open orders, and external codes. They should review evidence within their scope.

Also define the point at which returning to the old system becomes difficult. New receipts or shipments change the rollback problem. The plan must account for that work.

A backup alone is not a complete rollback plan. The business must know which records to trust. It also needs to keep the work performed during cutover.

Monitor the first live transactions

Watch the first receipts, picks, returns, and new product creations. These expose relationships that a static row count cannot.

Check rejected barcode lookups and unmapped buyer codes. Look for invalid size combinations and wrong unit conversions. Compare these findings with the pilot results.

Keep the crosswalk available to support staff. Do not leave it on one implementer's laptop.

If a mapping defect appears, assess its affected records before changing it. A simple master correction may be enough for an unused item. A variant already used in stock movements may need a controlled repair.

Keep the repair linked to the original migration evidence. That record helps distinguish a migration defect from a later setup change.

Common questions

Should we give every item a new code?

Only when the target design and business need justify it. Keep old references. Physical labels, open documents, and user searches still need to resolve correctly.

Can matching descriptions prove two items are duplicates?

No. Check the product specification and dimensions first. Then compare ownership, pack form, and other identity fields. Approve a merge only when those checks support it.

Is a matching total stock quantity enough?

No. Reconcile at the needed variant, location, lot, status, and unit levels. Offsetting errors can hide inside a balanced total.

Must all old history become live master data?

Not always. The business may retain history in another searchable form. Check dependencies and access needs before excluding records.

Preserve meaning before declaring success

The new system must identify the right product and support the right work. That is the test of a successful migration. A completed import job is only one part of that proof.

Build a reviewed crosswalk. Keep the valid variant combinations and resolve their units. Account for every source record. Reconcile detailed identities and balances, then test the workflows that use them. The total may look correct while thirty shirts carry the wrong size. These checks expose that error before the team starts to use the new system.

Migrated records must match what production uses, so see ERP for the apparel industry, the garment specification sheet, WIP reconciliation and the manufacturing analytics stack.

References

• Microsoft Learn — Product dimensions.

• Microsoft Learn — Product identifiers.

• GS1 — GTIN Management Standard, release 1.1.

• Microsoft Learn — Manage units of measure.

• Microsoft Learn — Import product data.

• Microsoft Learn — Product data entities.

• ApparelDiary — Apparel ERP checklist.