Key Takeaways
- For Plus merchants, Shopify began automatically upgrading some checkout.liquid customizations on January 6, 2026.
- For non-Plus merchants, Shopify says you need to finish the Thank you page and Order status page upgrade by August 26, 2026.
- Most migration pain comes from undocumented scripts, pixels, and apps living on the post-purchase experience.
- A clean migration starts with an inventory, not with opening the checkout editor and hoping everything is obvious.
If your Shopify store has been around for a while, the Thank you page and Order status page probably contain more business logic than anyone wants to admit.
That is why this migration keeps turning into a mess for merchants. The visible part looks simple. The hidden part usually includes a stack of scripts, pixels, surveys, affiliate logic, post-purchase offers, and support widgets that were added over time by different agencies, app vendors, or in-house teams.
Here is the current reality in plain English.
What changed, exactly?
Shopify has been moving merchants from legacy Thank you page and Order status page customizations to Checkout Extensibility.
Two dates matter:
- January 6, 2026: Shopify began automatically upgrading some
checkout.liquidcustomizations on the Thank you page and Order status page for Plus merchants after notice. - August 26, 2026: Shopify says non-Plus merchants need to complete their upgrade for the Thank you page and Order status page by this date.
If you are reading this after assuming you still had “plenty of time,” that assumption is now risky.
Why merchants are getting caught off guard
Most stores do not have one checkout customization. They have layers of them.
The usual list looks like this:
- Google Tag Manager or old analytics snippets
- Meta or affiliate tracking code
- NPS or post-purchase survey scripts
- reorder offers
- warranty or shipping protection upsells
- customer-support or ticket widgets
- custom event pushes into a CDP
When teams say, “Our Thank you page broke,” what they usually mean is one of three things:
- A script was removed and nobody realized it was still used.
- A pixel migrated poorly and reporting drifted.
- An app feature exists in the new model, but it was never reconfigured inside Checkout Extensibility.
The right way to audit this before it hurts revenue
Do not start in the editor. Start with an inventory.
Make one sheet with these columns:
- customization name
- what it does
- page location
- owner
- vendor or app
- whether it is still needed
- replacement method
- test status
Then review these buckets one by one:
1. Pixels and analytics
Anything sitting in additional scripts or old page code needs review first. If reporting matters to paid media, email, or affiliate teams, this is priority one.
2. Merchandising and upsell logic
If the Thank you page drives post-purchase revenue, confirm whether the current app supports checkout and post-purchase extensions instead of old script injection.
3. Operational widgets
Support tools, survey tools, and customer-message embeds often get forgotten because nobody sees them as “checkout.” They still break when the old model disappears.
What replaces the old setup?
The answer depends on what the customization actually does.
- Use app blocks where a compatible checkout app already supports the new architecture.
- Use custom pixels or app pixels for tracking and analytics.
- Use the checkout and accounts editor for supported content blocks and app experiences.
- Use Shopify Functions or app-supported logic for behavior that used to rely on older customization patterns.
The worst move is trying to force one replacement method onto every problem.
A five-step migration sequence that actually works
Step 1: Pull the upgrade report
Use Shopify’s upgrade tooling to see what customizations exist and which ones need action. This becomes the master checklist.
Step 2: Remove dead weight
Before you rebuild anything, ask whether it should still exist.
Every outdated script you delete now reduces future QA and cuts risk.
Step 3: Replace tracking before content
It is easier to spot a missing banner than a broken attribution stream. Replace analytics and ad tech first so you can test events cleanly.
Step 4: Rebuild revenue-driving blocks
After tracking is stable, move post-purchase merchandising, loyalty, or survey experiences into supported extensions or apps.
Step 5: Test with real scenarios
Run actual orders across:
- Shop Pay
- guest checkout
- returning customer checkout
- discount orders
- mobile checkout
- international market orders if relevant
Test the Thank you page, Order status page, and any follow-up links your support team sends to customers.
Common mistakes to avoid
Assuming your app vendor handled everything
Some vendors support the new model. Some only partially support it. Some require manual activation in the editor. Verify it yourself.
Leaving duplicate tracking in place
A common migration failure is keeping old snippets while adding new pixels. That creates double-fires and corrupts reporting.
Treating post-purchase as “marketing only”
These pages affect support, retention, subscriptions, surveys, referrals, and repeat purchase flows. Multiple teams need to sign off.
The practical deadline mindset
Do not aim to “finish before the deadline.” Aim to be stable at least a few weeks before it.
That gives you time to catch:
- broken events
- missing blocks
- app permissions issues
- lost support links
- market-specific checkout problems
If you are still discovering what is installed, you are not late yet. But you are definitely in the audit phase, not the procrastination phase.
