Replacing a beauty retail system involves more than installing new software. The harder task is establishing business definitions that remain usable after cutover: how shades and sizes are identified, how full-size products differ from samples, gifts and testers, how batches and expiry dates enter stock records, which loyalty balance is authoritative, and which system fulfils outstanding pre-orders and returns.
Products and inventory have a clear dependency: agree product identities and units before creating opening stock. Customer and transaction data can be cleaned and trial-migrated in parallel, with all four areas reconciled within the same cutover window. Business rules determine the migration plan; technical imports implement those rules.
Decide where each type of data belongs
The largest historical dataset is not necessarily the most useful in the new system. Importing every completed transaction can also import duplicate members, expired coupons, inactive products and unexplained fields. Define scope around continuity after launch, rather than everything the old system can export.
Separate data that will remain operational, data retained for reference, and data archived without entering the new system. For each category, specify the retention period, responsible department and access arrangements after the old system is retired.
| Data | Operational migration | Reference records | Decision before launch |
|---|---|---|---|
| Products | Active SKUs, barcodes, shades, sizes, units, prices and batch/expiry attributes | Discontinued items, former bundles and historical prices | Old-to-new code mapping and multiple barcodes per SKU |
| Inventory | Opening quantities by location, status, batch and expiry | Historical movements and counts | Physical-count cut-off and transfers in transit |
| Members | Valid identities, tiers, points, coupons and purchased entitlements | Historical interactions, services and campaigns | Deduplication, entitlement cut-off and personal-data scope |
| Transactions | Open orders, uncollected pre-orders, pending refunds and returns | Completed sales, payments, daily settlements and accounting records | Completion in the legacy system or fulfilment in the new one |
Set a reference time for each dataset. Points might use the available balance on the evening before cutover; inventory might use the physical count after store close; pending returns might include accepted requests whose refunds are not complete. Without a cut-off, ongoing business changes the result and prevents meaningful acceptance.
Rebuild product identities that support selling and counting
A product name and barcode are insufficient for beauty master data. Skincare varies by size, kit and travel format; cosmetics add shade, texture and range. Old and new packaging, domestic and international barcodes, store abbreviations and e-commerce identifiers may coexist. Define the target product model before mapping fields.
Use the SKU to organise shades, sizes and barcodes
Decide which attributes create separate SKUs and which are descriptive. Shades sold, counted and replenished separately need separate identities. Size affects pricing, inventory and promotions and should not exist only within the name. Where one SKU has several historical barcodes, distinguish the primary barcode, recognised legacy codes and retired codes so scanning does not create duplicates.
Distinguish fixed bundles from temporary promotional combinations. Fixed bundles may have independent pricing and stock rules; promotional combinations may be split into components at sale. Preserve components, quantities, price allocation and return rules, rather than copying only bundle names.
Distinguish full-size products, samples, gifts and testers
Full-size stock supports sales and replenishment; samples and gifts support campaigns and loyalty; testers support store demonstrations. Use separate product records or explicit product and stock types. If the old system combined them under one code, separate them using physical counts and purchasing or issue records. Where a reliable split is impossible, document the difference and have product, inventory and finance owners agree the opening treatment.
Acceptance is not the number of imported rows. Stores must scan, sell and return correctly; headquarters must analyse the right dimensions; receiving, transfers and counts must use the same identities. Test current products with multiple shades, sizes, old and new barcodes, and bundles from setup through return.
Migrate stock by physical quantity, location and status
A stock balance combines product identity, location, status and quantity. Warehouses, stores, department-store counters, pop-ups and goods in transit cannot be reduced to a brand-wide total. Within a location, saleable goods, gifts, testers, damaged goods, frozen stock and customer reservations are also different balances.
Freeze transactions before establishing opening stock
Set the last entry time for receipts, transfers, counts, sales and returns. A transfer dispatched before cutover but not yet received must either be received in the old system before extraction or handed over as an in-transit transaction. It must not be deducted on dispatch and then independently counted as a new opening receipt. Counters also need to reconcile unrecorded sales, daily settlement and documents awaiting transmission from the department store.
Use the physical count as the basis and the legacy ledger as a comparison. Count records should identify organisation, warehouse or store, bin, SKU, status, batch, expiry and quantity. Do not erase differences with a technical adjustment: record quantity, value, cause, owner and resolution, then obtain inventory and finance approval.
Carry forward only batch and expiry data that can be explained
For batch-controlled products, migrate batch numbers, production or expiry dates and their quantities. A total SKU balance cannot justify reconstructing batches by averages. Confirm missing details from labels, purchase documents and receiving records during the count. Mark untraceable stock separately and agree whether to quarantine it, restrict sales or apply another treatment. Do not manufacture a batch history.
Expiry alerts require dates and thresholds. Test near-expiry, expired, undated and multi-batch products, checking the brand’s display, warning and restriction rules and whether picking practice matches the configured issue sequence.
Align member identities, entitlements and tags
The objective is to recognise the same customer and honour existing commitments after cutover. Phone numbers, membership cards, WeChat OpenID and UnionID, and legacy member IDs may identify one person—or conflict because of shared numbers, changed numbers or input errors. Validate deduplication on samples before applying it in bulk. Preserve original records and the basis for every merge.
Reconcile valid entitlements as outstanding obligations
Define the cut-off, validity, frozen status and future usage rules separately for tiers, available points, unredeemed coupons, stored value and purchased benefits. Stored value and purchased benefits also carry financial and fulfilment obligations. Coupon records must distinguish issued, redeemed, expired and frozen states so redeemed coupons cannot become usable again.
Create an entitlement snapshot before migration. Reconcile total and active members, membership by tier, point balances, valid coupon counts and stored-value balances. Then inspect high-value customers, multiple accounts sharing a phone number and cross-channel accounts individually. Matching totals do not prove that the right customer received the right balance.
Retain beauty preference tags only when their basis is clear
Skin type, benefit, category, shade and brand-line preferences and repurchase-cycle tags need an identifiable source, update date and calculation rule. Recalculate from reliable history when rules have changed. Retire unexplained or stale tags and rebuild them from new transactions and interactions. Filter sensitive or free-text adviser notes according to the brand’s agreed purpose, minimum necessary scope, permissions and audit requirements.
Agree a handover route for every open transaction
Reservations, pre-orders awaiting collection, paid but unshipped orders, customer-held goods, returns, exchanges and pending refunds need an explicit decision: finish in the old system or continue in the new one. Preserve the next action, its owner and the state to which it must progress.
The handover record should include original order number, status, amount paid, quantity awaiting shipment or collection, member, selling and collection stores, reserved points or coupons, refund responsibility and payment evidence. If the order remains in the old system, define account access, duration and permitted operations. If migrated, preserve a traceable old-to-new reference and prevent duplicate shipment, refund or entitlement release.
Treat completed history according to use. Transactions still eligible for returns must remain searchable or referencable. Loyalty analysis needs product, value, date, channel and store dimensions. Original accounting and audit records may sit in an appropriate historical archive rather than the operational system.
Use trial migrations to refine rules, then rehearse the final version
The sequence is scope, mapping, trial migration, business validation, discrepancy closure, pilot and cutover. Start with representative samples to expose mapping and conversion problems. Keep rule versions and discrepancy records. Before launch, run at least one full or near-full-volume rehearsal using the same conversion rules as production.
The brand coordinates usable source data and field definitions from the legacy supplier. The new supplier provides templates, mapping, transformation, import tools and technical validation within scope. Product, supply-chain, loyalty and finance teams approve business rules and sign off results.
| Stage | Deliverables | Exit condition |
|---|---|---|
| Scope | Data inventory, destinations, cut-offs and owners | All four data groups have an agreed treatment |
| Mapping and cleaning | Dictionary, conversion rules and exceptions | Business owners approve definitions |
| Trial migration | Import results, reconciliations and samples | Critical differences closed; remaining impacts, owners and deadlines approved |
| Pilot | Store scripts, issues and corrections | Frequent transactions and exceptions validated |
| Cutover | Final data, handover and signatures | All four groups reconciled without unexplained differences; business and finance sign-off |
A rollback plan must specify triggering business measures, the decision-maker, how legacy entry resumes, how transactions created during cutover are reconciled, and which issues must close before a second launch. “Switch back if it fails” is not an executable plan.
Accept the migration through real beauty-store scenarios
Use the brand’s own products, members and orders to verify:
- Different shades and sizes scan, sell, return and decrement independently.
- Full-size products, samples, gifts and testers retain separate stock treatment through promotions and issue.
- Multi-batch balances in warehouses, stores and counters match counts; near-expiry and undated stock trigger the agreed response.
- Duplicate members merge correctly and tiers, points, valid coupons and purchased benefits remain consistent.
- Preference tags have explainable origins; unsuitable tags do not drive targeting.
- Pre-orders, unshipped orders, held goods and returns continue with traceable original references.
- Daily settlement, refunds and stock reconcile; ERP, WMS, e-commerce or counter-interface failures are recorded and handled through agreed retry or manual procedures.
Trace differences to business definitions, source data, mapping, configuration or interfaces. Progress only when issues are closed or their impact, owner and deadline have been explicitly accepted.
Match system capabilities to migration objects
The PEKON Smart Retail System covers products, store POS, promotions, orders, inventory, counts and operating analysis. PEKON CRM supports identities, tags, tiers, points and coupons. Beauty brands should also check full-size and non-saleable goods, batch and expiry management, reservations, pre-sales, stores and department-store counters against the beauty retail solution.
Classify each requirement as standard functionality, configuration, integration, custom development or unsupported, and validate it with brand data and scripts. System capabilities cannot repair unexplained historical data or physical discrepancies without business decisions. Brands at an earlier planning stage can use the five-step retail-system migration methodology to establish continuity, then add the beauty-specific data inventory described here.
Completion means continued fulfilment and reconciliation
Products must transact under the correct identities, stock must match physical goods and locations, members must be recognised with valid entitlements, and open orders must remain fulfilable. Verify those outcomes jointly through store operations, inventory counts, member queries and financial reconciliation.
Confirm rules, run trial migrations and close differences before cutover to reduce manual adjustments afterwards. Technology executes migration; the departments using the data and carrying the obligations must accept it.
Inventory the data before evaluating a cutover plan
List products, inventory, loyalty entitlements and open transactions. Decide what can migrate directly, what requires cleaning or rebuilding and what needs historical access only. Contact PEKON to discuss scope against store formats, interfaces and the available cutover window.
Frequently asked questions
Must every historical record move at once?
No. Product identities and units precede opening inventory. Member and transaction preparation can run in parallel and reconcile at the same cutover. Retain or archive historical detail according to returns, analysis, finance and audit needs.
Can total stock replace missing batch and expiry details?
No. Use totals for comparison, confirm batches through physical counts, and identify untraceable stock separately. Do not invent history through allocation or estimates.
Can full-size products, samples, gifts and testers share one code?
Where sales, issue, ownership or accounting treatment differs, separate them through product records or explicit types. Acceptance must demonstrate that they do not consume each other’s saleable stock.
Are member counts and point totals enough?
No. Check duplicate identities, shared phone numbers, cross-channel accounts, high-value customers, coupons, stored value and purchased benefits individually as well.
How should uncollected pre-orders and returns be handled?
Choose legacy completion or new-system fulfilment for each category. Preserve status, paid amount, outstanding quantity, member, store, entitlement commitments, refund ownership and payment evidence, and prevent duplicate processing.
Can the new supplier migrate data without legacy-supplier cooperation?
The new supplier cannot explain source data on the legacy supplier’s behalf. The brand must coordinate usable exports and definitions; technical work and business acceptance remain separate responsibilities. Assess missing data and alternative treatment before proceeding.
When has a trial migration passed?
Critical differences are fixed; remaining impacts, owners and deadlines are approved; and aggregate reconciliations and detailed samples meet the acceptance rules for products, stock, entitlements and transactions. A completed import or an identified problem alone is insufficient.