Ecommerce replatforming compliance checklist: do not lose ground when you migrate

Replatforming is one of the highest-risk events in the compliance lifecycle of an ecommerce store. Everything changes at once: the front-end codebase, the checkout flow, the data architecture, the app integrations and the infrastructure. Compliance work done on the old platform does not migrate automatically. Use our compliance audit checklist to baseline both environments.

Stores that were 80% WCAG compliant on their old platform often launch their new platform with violations they had already fixed years ago. Stores with solid PCI compliance on their hosted checkout often move to a headless architecture that inadvertently expands their PCI scope. The compliance debt from a migration can take months to identify and years to fully remediate.

This guide covers how to protect your compliance posture through a platform migration: what to do before, during and after.

Why replatforming is a compliance risk event

The structural reasons platform migrations reset compliance:

• New theme, new violations. Your old theme had been refined over years, with accessibility fixes applied iteratively. Your new theme is a starting point. It has never been audited. It will have violations. This is expected, but it means your compliance posture drops at launch and must be rebuilt.
• New app stack. Every app you migrate to or add on the new platform is a potential source of new scripts, new cookies and new data processing practices. Apps that were compliant on the old platform may not have equivalents on the new one. New apps may introduce PCI or privacy issues that did not exist before.
• Changed PCI scope. Replatforming often changes how card data flows through your system. Moving from Magento self-hosted (SAQ D) to Shopify Payments (SAQ A) simplifies PCI scope dramatically. But moving the other direction, or moving to a headless checkout that routes card data through a custom integration, can expand scope unexpectedly.
• Data migration and consent record loss. GDPR requires that consent records be maintained. When you migrate customer data from your old platform to the new one, consent records, DSAR history and cookie preference records may not migrate cleanly. You may launch with a customer database where you cannot prove consent was obtained for your marketing lists.
• New infrastructure, new security baseline. If you are migrating from a managed platform to a more custom architecture (common in headless migrations), you may be taking on new infrastructure responsibilities. Server security, SSL configuration and HTTP security headers need to be set up correctly on the new infrastructure.

Pre-migration: establish your compliance baseline

Before the migration project begins, run a comprehensive compliance scan of your current store. This is your baseline. It serves two purposes:

• Identifies what needs to be preserved. Which compliance fixes on your old platform must be replicated on the new one? Which custom accessibility work, which security headers, which privacy configurations must survive the migration?
• Provides a comparison point post-launch. After the new platform launches, you compare its compliance score to the old platform's baseline. Any regression is quantified and addressed.

The baseline scan should cover: all four compliance pillars (accessibility, PCI, privacy, AI Act), all key page types (homepage, category, product, cart, checkout, account) and include a manual inventory of all third-party scripts on payment pages.

Accessibility in platform selection criteria

Platform selection decisions have long-term accessibility implications that are not always evaluated during the RFP process:

• Native checkout accessibility. Shopify's checkout, Salesforce Commerce Cloud's checkout and BigCommerce's native checkout have invested in WCAG compliance. Custom headless checkouts built with React or Next.js have whatever accessibility the development team built in. Evaluate checkout accessibility before committing to a headless architecture.
• Theme accessibility standards. Does the platform's official theme library meet WCAG 2.1 AA? Shopify's Dawn theme is documented as WCAG-compliant. Some theme marketplaces sell themes with minimal accessibility. Request WCAG conformance documentation from theme vendors before purchasing.
• CMS and content accessibility. How does the platform handle alt text for product images? Are form labels enforced or optional? Does the platform's rich text editor produce clean, semantic HTML? Accessibility built into the content management layer is less work than retrofitting it after launch.
• App ecosystem accessibility. The apps available for the platform have varying accessibility quality. If your current compliance program relies on a specific app (for cookie consent, reviews or search), verify that a compliant equivalent exists on the new platform before committing to the migration.

PCI scope changes during migration: common scenarios

Understanding how your PCI scope changes before the migration prevents surprises:

• Magento self-hosted to Shopify Plus. Magento self-hosted with a payment gateway integration typically falls under SAQ D (the most demanding questionnaire). Shopify Plus with Shopify Payments falls under SAQ A (the simplest). This is a major compliance simplification. But if you use a Shopify checkout extension that involves a third-party payment form, verify your SAQ classification does not revert to SAQ A-EP.
• Shopify to headless (Next.js, Hydrogen). This is one of the most common replatforming directions for mid-market brands. Moving to headless often means using the Shopify Storefront API and a custom checkout experience. If the checkout experience involves any payment form elements that are not fully hosted by Shopify Payments, your PCI scope expands from SAQ A to SAQ A-EP or higher. This is frequently not anticipated during headless migration planning.
• WooCommerce to BigCommerce. WooCommerce self-hosted with WooCommerce Payments may have been SAQ A-EP. BigCommerce with a fully hosted payment gateway like BigCommerce Payments or Stripe Checkout moves to SAQ A. Confirm with your acquiring bank which SAQ applies to your new configuration before completing the migration.
• Any migration that changes your payment page URL. PCI DSS 4.0 requirements 6.4.3 and 11.6.1 mandate script authorization and change detection on payment pages. PCI ASV (Approved Scanning Vendor) scans target specific URLs. After a migration, update your ASV scan configuration to target the new checkout URL. A migrated store with the wrong ASV scan target has an unchecked payment page from a PCI perspective.

Data migration and privacy compliance

GDPR and CCPA obligations follow the data, not the platform. When you migrate customer data, you must preserve the privacy properties of that data:

• Consent records. GDPR requires that you can demonstrate consent was lawfully obtained for each marketing communication. If your old platform stored consent records (with timestamp, consent mechanism and consent text), this data must migrate with the customer record. If it does not, you cannot prove GDPR consent for your existing email marketing list. This may require re-permission campaigns post-migration.
• DSAR history. Data Subject Access Requests that were responded to on the old platform need to be accessible post-migration. A customer who submits a DSAR after migration should not receive a response that is incomplete because their data history from before the migration is inaccessible.
• Cookie preference records. If customers set cookie preferences on your old store, those preferences should not reset at migration without notification. A silent reset of cookie preferences means customers who opted out of tracking on the old site are tracked on the new one without re-consent. This is a GDPR and CCPA violation.
• Third-party data processors. If you are moving customer data to a new CRM, ESP or CDP as part of the migration, this may constitute a new data sharing arrangement. GDPR requires a Data Processing Agreement (DPA) with each processor. Verify DPAs are in place with all new processors before data migration begins. Stores selling internationally must also verify data transfer mechanisms for each market.

Testing compliance on staging

Before launch, run compliance scans on the staging environment. Staging scans catch the highest-severity violations before they are live:

• WCAG scan on all key page types. Staging scan should cover the same pages as your production baseline: homepage, category, product, cart, checkout (all steps) and account. Use the WCAG 2.1 AA ecommerce checklist to verify each page type. Compare results to your old platform baseline. Document any regressions.
• Manual checkout accessibility test. Keyboard-navigate the entire checkout flow on staging. Can you complete a purchase from product selection through payment confirmation using only a keyboard? Test with a screen reader. Does the checkout announcement flow make sense to a screen reader user?
• Script inventory on staging payment pages. Run a script inventory on your staging checkout. Every script present at this point should be intentional and authorized. No surprises at launch.
• Cookie consent staging test. Load your staging store in a fresh browser (no cookies). Does the consent banner appear before any non-essential scripts fire? Does the consent preference center work? Does rejecting all cookies actually prevent non-essential scripts from running?
• SSL and security header verification. Check that your staging environment has correct SSL configuration, HSTS headers, X-Frame-Options and Content Security Policy. These should match or improve on your old platform's security header configuration.

Launch day compliance verification

On launch day, run a compliance scan immediately after DNS propagation completes. The launch scan serves as the official record of your compliance state at go-live. It documents:

• Your compliance score at launch across all four pillars.
• Any violations present at launch (which you will need to remediate with documented SLAs).
• The script inventory on payment pages at launch (the authorized baseline for ongoing PCI monitoring).

If the launch scan reveals critical violations that were not in the staging scan, investigate immediately. A difference between staging and production scans indicates either a staging configuration issue or a production-only element (a production-only script, a production-only promotional banner) that introduced violations.

Common replatforming compliance pitfalls

Shopify to headless: checkout accessibility regression

Shopify's native checkout is WCAG-compliant. When a brand moves to a headless architecture with a custom checkout built in React, the accessibility of the checkout depends entirely on the development team's implementation. Custom focus management, ARIA roles and keyboard navigation must be built explicitly. Most headless checkout implementations do not cover these on the first version.

Magento to BigCommerce: losing CSP configuration

A Magento store with carefully configured CSP headers may not have those headers replicated on BigCommerce without explicit effort. BigCommerce's default CSP configuration is less restrictive. After migration, verify that your CSP headers are at least as restrictive as they were on the old platform.

WooCommerce to any platform: plugin-based accessibility fixes

WooCommerce stores often have WordPress plugins that provide accessibility fixes (skip navigation, ARIA labels, focus management). When migrating to a new platform, these plugin-based fixes do not transfer. They must be rebuilt as native features or custom code on the new platform.

Any migration: new analytics and tracking scripts

Platform migrations are often accompanied by CRM migrations, ESP migrations and analytics platform changes. Each new tool introduces new scripts, new cookies and new data flows. A migration where you simultaneously switch from Google Analytics to Segment, from Klaviyo to Brevo and from Yotpo to Okendo introduces four new consent and data processing configurations at once.

90-day post-migration monitoring plan

The first 90 days after a platform migration are the highest-compliance-risk period. The new platform is being actively configured, apps are being installed and the development team is building post-launch features. Monitoring during this period should be intensive:

• Week 1-4: daily compliance scans. Run daily scans on all key pages. Compare each day's results to the launch scan. Any new violations should be triaged immediately. The goal is to identify launch violations and migration-introduced regressions before they accumulate.
• Week 1-4: weekly script inventory on payment pages. After each week of post-launch work, run a script inventory on checkout and payment pages. Verify no unauthorized scripts have been added.
• Month 2-3: standard monitoring plus post-migration audit. By week 8, you should have addressed all critical violations from the launch scan. Schedule a formal post-migration accessibility audit (manual testing by a specialist) for week 8 to 12. This audit validates that the new platform meets your accessibility baseline and documents your compliance posture for the first annual cycle on the new platform.
• 90-day checkpoint: compliance comparison report. At day 90, compare your compliance score to your pre-migration baseline. You should be at or above your old platform's score. If you are not, you have compliance debt from the migration that needs to be addressed before it crystallizes into legal exposure.

Frequently asked questions

Does replatforming reset your compliance status?

Effectively, yes. A new platform means a new codebase, new checkout flow, new data architecture and new app integrations. Stores that were 80% WCAG compliant often launch their new platform with violations they had already fixed years ago.

How long should you monitor compliance after replatforming?

Run daily compliance scans for the first four weeks post-launch, then weekly for months two and three. Schedule a formal post-migration accessibility audit between weeks 8 and 12.

Does moving to headless commerce change PCI scope?

Often, yes. Moving from Shopify Plus (SAQ A) to a headless checkout with custom payment form elements can expand PCI scope to SAQ A-EP or higher. Confirm your SAQ classification with your acquiring bank before completing the migration.