Company Store Migration Guide: Inventory, SSO, Payments, URLs, and Cutover
A company-store migration is not a catalog copy. It transfers products, stock, identities, balances, financial rules, integrations, customer history, and public entry points between operating systems. The safest programs define what must remain true after cutover, reconcile each transferred record, rehearse failure paths, and keep a tested rollback window. This guide gives Brand Operations, IT, Finance, Procurement, and Supply Chain one execution plan for doing that work without turning launch night into improvised data repair.
Start with migration outcomes, not a launch date
A fixed date is useful only after the team agrees on the conditions that make the new store acceptable. Write those conditions as measurable outcomes: every active product has an approved destination record; sellable inventory reconciles within an agreed tolerance; eligible users can sign in; balances do not increase or disappear; taxes and payment routes behave as approved; high-value URLs resolve correctly; and support can trace an order from submission through fulfillment. Create a decision group with one accountable owner. Brand Operations owns the shopper and merchandising outcome. IT owns identity, integrations, access, and technical rollback. Finance owns funds, balances, tax treatment, and reconciliation. Supply Chain owns physical counts and stock disposition. Procurement owns vendor obligations, data return, deletion, and exit evidence. Customer Support owns incident routing and user communication. No single vendor should be allowed to declare success for controls owned by these functions. Translate the outcomes into release gates. A gate has an owner, evidence, a deadline, and a blocking threshold. “Test payments” is not a gate; “approved test orders in every supported payment path settle, refund, and appear in the finance export with matching currency and tax” is. Record the exceptions that can be accepted after launch and those that force a delay. This distinction stops small cosmetic issues from derailing the move while preventing teams from waving through defects that corrupt money, access, or stock.
Choose the migration pattern before designing the plan
Three patterns cover most enterprise moves. A big-bang cutover moves all users and transactions at once. It offers the shortest period of dual operation but creates the largest blast radius. A phased migration moves regions, business units, catalogs, or user groups in waves. It produces better learning and a smaller incident surface, but shared balances, stock, and reporting may become harder while two stores operate. A parallel run keeps both stores available for a defined period and sends only selected transactions to the new one. It improves comparison and rollback confidence, but demands explicit rules that prevent duplicate ordering or balance spending. Select the pattern from dependency and reversibility, not preference. A simple store may tolerate a short big-bang window; a multinational program with regional catalogs, several warehouses, allowances, or local payment methods usually benefits from waves. If exports cannot freeze consistently or cohorts cannot be isolated, parallel operation may be unsafe. Document the routing rule in one sentence. Examples include “North America employees place all new orders in the new store after 18:00 UTC; open orders remain in the old platform” or “pilot users use the new store while all others remain read-only in the legacy system.” Every support script, redirect, identity assignment, and reporting query should implement that same rule.
Build a migration inventory and control ledger
Discovery should create a ledger, not a slide. List every data domain, source, owner, extraction method, sensitivity level, transformation, destination, reconciliation rule, retention period, and deletion obligation. Include products, variants, images, category structures, price books, localization, tax classes, warehouse stock, inbound purchase orders, users, groups, entitlements, balances, orders, shipments, returns, gift codes, invoices, approval rules, audit logs, integrations, webhooks, domains, certificates, redirects, analytics, and support knowledge. For each domain, label the action: move, recreate, reference, archive, or retire. Historical orders may remain in a read-only archive; current inventory and unresolved returns normally must move or remain operational until closure. This classification prevents low-value imports from obscuring records that drive open liabilities. Add control totals before extraction: active user count by cohort, available and reserved units by warehouse and stock-keeping unit, total balance liability by currency, open order count and value by state, unredeemed code value, and the number of indexed URLs by template. Hash or checksum exported files where supported and store them in restricted, versioned locations. The ledger becomes the migration chain of custody and the evidence used at go/no-go.
Define the source-of-truth and freeze strategy
A migration fails when two systems can both change the same field without a deterministic winner. For every domain, specify the authoritative system before, during, and after cutover. The product information system may own descriptions, the warehouse system may own available stock, the identity provider may own eligibility, the finance ledger may own balance liability, and the store may own checkout and order state. Do not let a convenient export redefine authority. Choose freeze windows by volatility. Static assets can freeze days before launch. Catalog edits may freeze one business day before. Balances, inventory, and open orders often need a final delta only minutes before routing changes. If a full freeze is impossible, record a watermark such as an updated timestamp or monotonically increasing identifier and define how late changes are captured. Require clocks and time zones to be explicit. Separate business freeze from technical freeze. Merchandisers may stop edits while warehouse receipts continue. Users may be blocked from placing new orders while fulfillment events still update open orders. A field-level matrix prevents the common mistake of treating the whole platform as either “on” or “off.” It also reveals whether the source vendor can provide a dependable final export and whether a second extraction can be compared with the first.
Map catalog, variants, prices, and media deliberately
Product migration is a semantic mapping exercise. Start with a crosswalk between old and new identifiers: product, variant, stock-keeping unit, supplier item, warehouse item, category, tax class, price book, currency, and localization key. Never assume two fields with the same name mean the same thing. One platform may treat color as a free-text option while another requires a variant dimension; one may include tax in displayed price while another adds it at checkout. Define transformation rules in a reviewed mapping table. Include allowed values, null handling, truncation, character encoding, units of measure, rounding, image order, accessibility text, minimum quantities, back-order behavior, personalization fields, and regional availability. Flag products that cannot be represented without redesign. A human merchandising review is still required after automated validation because technically valid data can produce a confusing storefront. Preserve stable external identifiers in dedicated reference fields. They support reconciliation, redirects, support lookups, and rollback. Validate ordinary items, bundles, personalized products, discontinued stock, multiple currencies, long localized descriptions, and cohort-restricted products.
Reconcile inventory as a financial control
Inventory is more than a quantity. For every warehouse and item, distinguish on-hand, available, reserved, damaged, quarantined, in-transit, back-ordered, and allocated units. Confirm whether the source and destination calculate availability the same way. A single “quantity” export can silently turn reserved units into sellable stock or hide goods that still belong to the company. Choose a cutover method. A physical count provides the strongest baseline but may be impractical across locations. A system count plus targeted cycle counts is often workable when high-value and high-velocity items receive extra scrutiny. Record the snapshot time, pending receipts, open picks, unposted adjustments, and transfers between warehouses. Freeze new reservations or route them to one system only while the delta is applied. Reconcile at three levels: units by item and location, total inventory value under Finance’s approved valuation method, and exception value by reason. Set tolerances before seeing the result. Every variance needs an owner and disposition: correct the destination, correct the source, accept with a documented reason, or block launch. Keep old and new identifiers in the exception log so support can trace a mismatch after cutover.
Migrate users, groups, and single sign-on safely
Identity migration should preserve eligibility and least privilege, not copy every legacy account. Begin with authoritative user sources, group ownership, joiner and leaver timing, regional access, administrator roles, and any recipient-only or guest flow. Map immutable identifiers carefully. Email addresses change; a stable workforce or directory identifier is usually safer for matching when both systems support it. For single sign-on, document the protocol, issuer, audience, reply address, logout behavior, signing certificates, encryption requirements, claims, group mappings, session lifetime, multifactor rules, and break-glass access. Microsoft’s current deployment guidance recommends planning pilot users and testing sign-in before broad rollout; staged migration is especially valuable when claims or conditional-access rules differ. If the store supports SAML or OpenID Connect, test both identity-provider-initiated and service-provider-initiated paths where applicable, expired sessions, unassigned users, disabled accounts, duplicate emails, and mobile browsers. Provisioning and authentication are separate controls. A person may authenticate yet have the wrong region, allowance, or access. Test create, update, suspend, reactivate, and delete flows. Keep two tested emergency administrator accounts outside the primary federation path, protect and monitor them, and retain the legacy connection until representative cohorts complete real sign-in tests.
Preserve balances, credits, and approval rights
Balances are liabilities and require ledger-grade handling. Identify every value type: employee allowance, promotional credit, gift code, refund credit, departmental budget, points, payroll deduction, or prepaid fund. For each, document currency, expiration, funding source, ownership, transfer rule, tax treatment, negative-balance behavior, and whether it can be combined with another payment method. Export a closing ledger, not just current totals. At minimum include user or account identifier, balance type, opening value, debits, credits, pending authorizations, expiration, and closing value. Assign a unique migration transaction identifier to every imported adjustment. Reconcile counts and sums by currency and cohort; never net different currencies or value types. If balances cannot be imported directly, define a controlled replacement instrument and communicate how old evidence maps to the new value. Approval authority also has monetary effect. Map approvers, limits, substitutions, escalation, and delegation dates. Test the boundary values, absence coverage, and terminated approvers. Finance should sign off on the balance reconciliation; business owners should sign off on budget and approval behavior. Users should see a clear opening balance and a support path without exposing sensitive financial details.
Redesign payment and tax flows without expanding risk
List every payment route: corporate card, personal card, purchase order, invoice, internal chargeback, payroll deduction, stored credit, or mixed payment. Draw the data flow from browser to processor, store, finance system, and reporting destination. The Payment Card Industry Data Security Standard applies to environments where payment account data is stored, processed, or transmitted; changing vendors or checkout architecture can change scope. Confirm the new design and validation obligations with qualified payment and security owners rather than assuming a hosted checkout eliminates all responsibilities. Never migrate raw card details. Migrate processor tokens only when the processors and contracts support a secure token transfer with an agreed mapping and validation method. Otherwise ask users to re-enter payment information. Remove card data from ordinary exports, tickets, and logs. Test authorization, decline, partial payment, capture, settlement, refund, void, chargeback evidence, and reconciliation for every supported currency and region. Tax behavior must be approved separately. Compare product tax classes, ship-from and ship-to logic, exemptions, invoice fields, rounding, and cross-border duties. Use controlled test addresses and known scenarios. A technically successful order with the wrong tax or payer is not a successful migration.
Reconnect integrations, webhooks, and operational files
Create an interface register with owner, direction, authentication, endpoint, data contract, frequency, retry policy, idempotency rule, rate limit, monitoring, and recovery procedure. Include warehouse management, enterprise resource planning, human resources, identity, tax, payment, analytics, shipping, customer support, email, and procurement systems. Scheduled file transfers deserve the same rigor as application interfaces. Treat event names as insufficient evidence. Compare field meaning, required values, ordering guarantees, timestamps, and state transitions. Generate a correlation identifier from storefront order through warehouse and carrier events. Consumers should handle retries without duplicating orders or balances. Secret rotation and endpoint allowlists must be ready before cutover, with old credentials retained only for the approved rollback period. Run contract and end-to-end tests. A webhook returning success does not prove downstream posting. Trace a representative order into fulfillment, shipment, finance, support, and analytics; test delayed, duplicate, malformed, and out-of-order events. Alert on business outcomes such as orders missing warehouse acknowledgment, not only server errors.
Preserve URLs, search signals, and user entry points
Create a one-to-one URL map for public and commonly bookmarked pages: home, categories, campaigns, products, help content, sign-in, and regional paths. Google’s current site-move guidance recommends testing the new site, mapping old to new URLs, using server-side permanent redirects where possible, updating canonical and internal links, submitting the new sitemap, and monitoring both old and new traffic. It also advises keeping redirects for at least one year and avoiding irrelevant many-to-one redirects. Separate public discovery from authenticated navigation. Search engines may not index the private store, but employees still rely on bookmarks, intranet links, emails, QR codes, and campaign pages. Update those sources and make old entry points resolve to the nearest valid destination. Do not redirect every removed product to the home page; return a useful replacement or an appropriate not-found response. Before launch, crawl the new site for broken links, accidental indexing blocks, incorrect canonical references, missing language annotations, redirect chains, and mixed environments. Monitor error logs, search reporting, analytics, and support contacts after cutover. URL preservation is both a search-control task and a user-continuity task.
Use a test matrix that mirrors real operating risk
Unit tests and vendor demonstrations are necessary but not sufficient. Build scenarios across user cohort, region, device, identity path, product type, inventory state, payment method, currency, tax case, shipping option, approval rule, and fulfillment location. Give every scenario expected results and downstream evidence. Prioritize risky combinations rather than trying every permutation. Include a new employee, departing employee, administrator, guest recipient, zero-balance user, split-funded order, personalized product, last unit, back order, tax-exempt destination, rejected approval, refund, cross-border shipment, and interrupted session. Test accessibility and localized content with real readers. Confirm that support can find the order and explain the state. Run a dress rehearsal from production-like exports through import, reconciliation, routing, and rollback. Measure duration and manual effort. The rehearsal should produce the same evidence pack required on launch night: extraction checksums, mapping results, record counts, variance logs, identity tests, payment evidence, interface traces, redirect tests, and owner approvals. Fix the process, not just the defects.
Define go/no-go gates and cutover command
Use one runbook ordered by time and dependency. Each task needs an owner, planned time, actual time, evidence link, status, and rollback effect. Include communication checkpoints, freeze start, final extracts, imports, reconciliation, identity assignment, integration activation, payment verification, routing changes, public redirects, smoke tests, and business acceptance. Establish a command lead who does not execute a fragile technical task. That person maintains the timeline, asks for evidence, records decisions, and controls communication. Domain leads report facts in a standard format: completed, evidence, variance, risk, and next action. A dedicated incident channel is useful, but the runbook remains the decision record. Go/no-go should evaluate the predefined gates, not optimism or sunk cost. Typical blockers include unreconciled balance liability, unexplained inventory variance above tolerance, failed sign-in for a required cohort, an unsafe payment path, missing warehouse acknowledgments, inability to restore old routing, or an untested rollback dependency. Cosmetic issues can move to a post-launch list only when their impact and owner are explicit.
Make rollback a product, not a paragraph
Rollback is a tested operating state. Define the latest safe decision point and what data must be captured before returning traffic. Reversing a redirect is easy; reconciling orders placed in the new store is not. The plan must say whether new orders are canceled, completed in the new system, or re-entered in the old one, and how stock and balances are adjusted exactly once. Maintain the legacy environment, credentials, integrations, domains, and support knowledge for the approved rollback window. Take final backups and verify restoration. Keep a delta ledger of every transaction created after the freeze. If the cutover is reversed, apply compensating entries from that ledger and reconcile before reopening the old store. Define rollback triggers and authority in advance. Examples include a critical identity outage beyond the maximum tolerated duration, material balance corruption, widespread payment failure, or loss of warehouse routing. A decision should not depend on whether a particular executive can be reached at midnight. After rollback, communicate clearly, preserve evidence, and schedule a new rehearsal rather than attempting repeated unplanned cuts.
Operate hypercare with business-level signals
Hypercare begins when routing changes. Staff Brand Operations, IT, Finance, Supply Chain, vendor support, and customer support for expected peaks; publish severity, response, escalation, and regional handoff rules. Monitor leading indicators every few minutes at first: sign-in success by cohort, store availability, cart errors, checkout completion, payment authorization, orders awaiting warehouse acknowledgment, stock rejection, approval backlog, email delivery, and support contacts. Reconcile financial and inventory totals at scheduled checkpoints. Compare with an appropriate baseline, but expect launch communications to change traffic volume. Use one incident register with user impact, affected records, containment, owner, and correction evidence. Avoid silent database edits. Repairs to stock, balances, orders, or permissions need an auditable reason and second check. Reduce monitoring only after stable periods and completed reconciliations.
Decommission the old platform with evidence
Do not decommission at launch. Close open orders, returns, credits, invoices, chargebacks, and support cases. Confirm required history is accessible, then validate and retain final exports under approved rules. Revoke integrations and administrator access in a controlled order. Remove secrets, disable user authentication, close scheduled transfers, update monitoring, and release domains only when redirects and legal needs allow. Procurement should obtain the vendor’s contractually required deletion or return evidence, including backups and subprocessors where applicable. Finance should close prepaid funds and outstanding credits. Archive the migration ledger, mapping files, reconciliations, test evidence, approvals, incidents, data-return records, and final configuration. Record lessons against future operating controls. The project is complete only when residual liability is owned, not when the old storefront disappears.
A reusable 30-60-90 day migration plan
In days 1–30, appoint owners, choose the migration pattern, complete the ledger, secure exports, classify data, map identifiers, confirm contracts, and define gates and tolerances. Run representative proofs for catalog, identity, balance, payment, inventory, integrations, and URLs. The deliverable is an approved design and an exception register. In days 31–60, configure the new store, build transformations, connect identity and interfaces, create redirects, migrate a production-like snapshot, and execute scenario testing. Reconcile every domain and run a first dress rehearsal. The deliverable is a measured runbook with known duration, staffing, and rollback steps. In days 61–90, close critical exceptions, run the final rehearsal, train support, confirm communications, execute cutover, operate hypercare, and begin controlled decommissioning. Adjust the timeline for scale and regulated review; do not compress finance, security, or reconciliation gates just to preserve a public launch date. The following scorecard can be copied into the runbook:
| Gate | Evidence | Blocking threshold | Owner |
|---|---|---|---|
| Catalog | Record counts plus sampled merchandising review | Any active required item missing or materially misrepresented | Brand Operations |
| Inventory | Units and value by item and location | Unexplained variance above approved tolerance | Supply Chain and Finance |
| Identity | Cohort sign-in, provisioning, and role tests | Required cohort or emergency access fails | IT |
| Balances | Count and value by type and currency | Any unexplained liability difference | Finance |
| Payments and tax | Authorization through refund and ledger export | Unsafe scope, failed required route, or wrong tax/payer | Finance and Security |
| Integrations | End-to-end trace with retries | Required downstream acknowledgment missing | IT and Operations |
| URLs | Redirect crawl, canonical checks, bookmarks | High-value entry point breaks or routes irrelevantly | Digital owner |
| Rollback | Timed rehearsal and delta-ledger test | Old route or compensating entry cannot be restored | Command lead |
Conclusion: migrate the operating model, then the storefront
The visible store is only the front door. A durable migration transfers control over identity, money, inventory, orders, integrations, search entry points, and vendor exit obligations. Teams that define authority, reconcile with pre-agreed totals, rehearse cutover and rollback, and keep evidence can move quickly without accepting invisible liabilities. Use the scorecard as a release contract, and allow the business owners of each risk to decide whether their gate is satisfied. Once the migration design is approved, Giftpack can serve as the execution layer for a new enterprise storefront, product sourcing, inventory, recipient access, and global fulfillment within the confirmed scope. Explore Giftpack’s enterprise gifting infrastructure and connect the migration controls in this guide to an implementation discussion; Giftpack does not replace your identity, payment, tax, legal, privacy, or employer decisions.
Sources and last verification
- Google Search Central: How to move a site — verified August 31, 2026.
- Microsoft Entra: Plan a single sign-on deployment — verified August 31, 2026.
- Microsoft Entra: Application and authentication migration best practices — verified August 31, 2026.
- OpenID Connect Core 1.0 — verified August 31, 2026.
- PCI Security Standards Council: PCI DSS — verified August 31, 2026.
- Best Enterprise Company Store Platforms, Global Company Store Operations, Global Swag Fulfillment Models, and Corporate Gifting Vendor Security Checklist — verified August 31, 2026.