Migrate from Adobe Commerce to Magento Open Source without rebuilding the store
If a renewal, a licensing change or a hosting requirement is pushing you toward the free OSL-3.0 edition, the good news is that the code is largely shared. Magento Open Source and Adobe Commerce run on the same core, so the work centers on four things: auditing which Commerce-only modules and data your store depends on, replacing paid features with extensions, moving hosting off Adobe's cloud, and testing the result before cutover. Your store's design, catalog structure and most custom code usually carry over unchanged, which is why this path is usually shorter than a re-platform. The work is normally led by an in-house platform team, often with an implementation partner for the module audit, the extension selection and the hosting build. Your team owns the business decisions, such as which paid features you can give up and which you must replace, while the partner or your engineers handle code removal and infrastructure. Ask your team to list every Adobe Commerce feature that is actively used, not just licensed. The effort and risk depend mainly on how many of those features are B2B or otherwise paid, and on how much custom code touches them. Confirm these points with your Adobe account team and your own environment before you commit to a schedule.
Plan the hosting change early, because it often carries more risk than the code. Adobe documents Varnish as the full-page cache for self-managed installations, while cloud-hosted Adobe Commerce uses Fastly, so your caching layer, search, queues and cron jobs must be rebuilt in your own environment. Check the system requirements for the release you choose, since Adobe supports only the listed combinations of PHP, database, OpenSearch, Redis or Valkey, RabbitMQ and nginx. The Adobe Commerce system requirements page is the natural starting point for that comparison. Before cutover, run the full order, checkout, customer and admin workflows on a staging copy of production data, and keep a tested rollback path to the Adobe Commerce environment until the first full business cycle has passed. Also confirm that you still receive security patches for the release you adopt, since Adobe's lifecycle policy and the community's patch cadence differ. Ask your partner for a written test plan, a migration runbook and a list of decisions the business has signed off.
Which Adobe Commerce features map to Magento Open Source and which need rework
This table maps Adobe Commerce capabilities to their Magento Open Source equivalents and marks each as clean, needs rework or gap. Read each row as a starting point: confirm every module and extension against your own installed code and the Adobe documentation before planning cutover. The main takeaway is that the Magento codebase carries over, but B2B, cloud pipelines and some caching and merchandising features need replacement work.
| Capability | Magento Open Source equivalent | Status |
|---|---|---|
| B2B company accounts and roles | Open-source extensions or custom development; Commerce B2B modules are not included in Open Source | Needs rework |
| Shared catalogs and company-specific pricing | Replace with an open-source B2B extension or custom catalog rules; confirm each price rule against your data | Needs rework |
| Negotiable quotes | No built-in equivalent in Open Source; plan an extension or custom quote flow | Gap |
| Purchase orders and requisition lists | No built-in equivalent in Open Source; plan an extension or custom workflow | Gap |
| Full-page caching on Fastly (cloud) | Varnish is the documented full-page cache for self-managed installs; Fastly configuration must be rebuilt | Needs rework |
| Cloud deployment pipelines and environments | Replace with your own CI/CD and infrastructure as code; Adobe's cloud pipelines do not carry over | Needs rework |
| Staging and environment management | Build your own staging environment that mirrors production; confirm the version and extension set match | Needs rework |
| Adobe support and SLAs | Community and partner support only; vendor support must be contracted separately | Gap |
| AI merchandising | No open-source equivalent in Magento Open Source; confirm which merchandising features your store actually uses | Gap |
| clearCart GraphQL mutation | Available in Magento Open Source 2.4.9; confirm your front end calls it on that release | Clean |
What data and integrations carry over, and what to rebuild
Magento Open Source runs on the same codebase and database schema as Adobe Commerce, so most catalog, customer, order and content data stays where it is. The work concentrates on the services and endpoints that only exist in Adobe's cloud or paid edition, and on the connections to payment, shipping, ERP, PIM and search that you must verify against your own code.
Catalog, customers and orders
Products, categories, customer accounts, orders and their history live in the Magento database schema that Open Source shares with Adobe Commerce, so they usually stay in place during a downgrade. Confirm this on a copy of your production database by running the upgrade and reindex steps on staging. Check custom attributes, customer groups and order statuses added by Commerce-only modules, since those tables or rows may depend on a feature you are removing.
Content and page structure
CMS pages, blocks, widgets and content staging data are stored in the database and carry over with the store. Content staging and scheduled updates are Commerce-only features, so any staged content or scheduled changes need a decision before cutover. Review CMS blocks that call Commerce-only widgets or components, because they will render empty or error on Open Source without a replacement.
URLs and redirects
Keep the existing URL rewrites and 301 redirect rules so search rankings and bookmarks survive the move. Export the URL rewrite table from the current store and compare it with the rewrites on the Open Source instance after reindexing. Check any redirects that point to Commerce-only pages or that depend on a custom rule set maintained through the Adobe admin.
Fastly and Adobe cloud services
Cloud-hosted Adobe Commerce uses Fastly for full-page caching, while self-managed installations use Varnish. Fastly service configuration, its VCL and any Adobe-managed cloud variables do not transfer. Plan a Varnish configuration, a cache purge workflow and a new CDN or edge setup, and confirm that Adobe's cloud-only deployment settings are removed from your environment files.
Commerce-only APIs and endpoints
Some GraphQL and REST endpoints, B2B and company APIs, and Commerce-only integration points are not in Magento Open Source. Scan your integrations, custom modules and front-end clients for calls to Commerce-only endpoints, and map each one to an Open Source equivalent or a custom module. The 2.4.9 release notes state that the clearCart mutation is now available in Open Source, which shows that some gaps close over time, so verify each endpoint against the release you run.
Payment, shipping, ERP and PIM links
Payment gateways, shipping rate providers, ERP connectors and PIM sync jobs usually run as extensions or custom middleware that call the store's APIs. Inventory each connection, its credentials, its webhook or cron schedule and its data direction. Test every connector against the Open Source build, because a connector written for Commerce-only APIs or a B2B company model will fail silently if you do not check order and stock sync end to end.
Search indexes and content security
Search indexes, including OpenSearch, are rebuilt from the database during reindexing, but their configuration, synonyms and any custom index mappings must be copied across. Confirm that OpenSearch 3 and Redis or Valkey versions match the support matrix for the release you target. Also review your Content Security Policy rules, because restrict mode is the default on storefront and admin payment pages from 2.4.7, and third-party scripts from payment or search widgets may need explicit allowances.
How the migration runs from inventory to decommission
The sequence moves a live Adobe Commerce store to Magento Open Source in controlled stages, so every Commerce-only dependency is known, tested and replaced before customers depend on the new stack. Each step ends with a written output that the next step relies on.
Inventory Commerce-only modules and data
Start by listing every Adobe Commerce module, configuration setting, GraphQL mutation, admin feature and integration that the store actually uses, including B2B company accounts, shared catalogs, quotes and requisition lists. Compare the code and the database against the Open Source feature set, and record which data the store holds that Open Source cannot represent. The output is a module register that names each dependency, its owner, whether it is used in production, and the replacement or removal decision. The step is done when the business owners have signed off on the register.
Confirm the target version and stack
Choose the Magento Open Source release line and check it against Adobe's system requirements for PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx, because Adobe supports only the listed combinations. Confirm the support window in Adobe's lifecycle policy for the chosen release, since the 2.4.x lines have different end-of-support dates. The output is a version and stack decision record that the hosting team and the store owners both approve, and it defines the baseline that the pilot must reproduce.
Remove Commerce-only modules on a staging copy
Build a staging copy of production code and data, then disable and remove the Commerce-only modules in the order the module register sets out, running the database upgrade and static content deploy after each removal. Replace paid features with the extensions or custom code selected in the register, and record which extensions were installed, their versions and any patches. Check custom modules that depend on removed classes or configuration. The output is a tested extension list and a working staging store that passes the agreed checkout, account and admin test cases.
Pilot and test on staging
Run functional, regression and performance tests against the staging store with production-like catalog size, order history and integrations such as payment, tax, shipping, ERP and email. Review the content security policy in restrict mode on payment and admin pages, because storefront payment flows often break there. Include the cache layer you will run after cutover, Varnish for self-managed installations, and test purge behavior for catalog and price changes. The output is a signed test report with open defects triaged and a go or no-go recommendation.
Stand up hosting outside Adobe's cloud
Provision the new production environment in your own cloud account or data center with the same stack that passed the pilot, including web nodes, database replication, search, cache, queue and backups. Configure TLS, firewalls, monitoring and secrets handling, and set up the image and media storage path that the Adobe cloud previously managed. Verify that the environment is patched and that the team can deploy to it through your own pipeline. The output is a hosting runbook and a restore test showing the environment can be rebuilt from backups.
Run a parallel period with Adobe still live
Keep the Adobe Commerce store in production while the Magento Open Source store receives a copy of the catalog, customers and orders on a schedule you define. Compare order totals, tax, stock levels, customer logins and search results between the two stores, and log every discrepancy with its root cause. Confirm that inbound integrations and webhooks can be pointed at the new store without loss. The output is a reconciliation log showing that differences are explained or fixed, and a list of open items that must close before cutover.
Cut over with a rollback plan
Write a cutover runbook with a freeze window for orders and catalog changes, the final data sync, DNS and certificate changes, cache warming, integration switches and the post-cutover checks. Define the rollback trigger and the exact steps to return traffic to Adobe Commerce, including how orders placed on the new store are handled if rollback happens. Rehearse the runbook at least once on staging. The output is a signed cutover runbook and a completed cutover record with time-stamped checks.
Decommission Adobe cloud resources after retention
After the new store has run stably and the agreed hold period has passed, retain a final backup of the Adobe Commerce code, database, media and configuration, then cancel or downgrade the Adobe-managed environments according to the terms in your ordering document with Adobe. Revoke the access keys, integration tokens and service accounts that existed on the Adobe side. Confirm the final invoice and any remaining contract obligations with Adobe, and archive the module register and test reports. The output is a retained backup set, a decommission record and a confirmed end date for each Adobe resource.
What drives cost and duration in this migration
This table lists the factors that move the cost and timeline of stepping down from Adobe Commerce to Magento Open Source, and how each one changes the work. Read each row as a lever: the cost components and quote questions are ones you can request from any implementation partner before work starts.
| Driver | Why it moves cost or time | How to keep it down |
|---|---|---|
| Commerce-only modules in use | Each B2B, staging, or cloud-specific module in use needs a replacement extension, a custom build, or a documented feature drop, and each replacement needs its own testing. | Complete the module audit first, remove unused modules, and decide keep, replace, or drop for each one in writing. |
| B2B complexity | Company accounts, shared catalogs, quotes, and requisition lists touch pricing, permissions, and checkout, so they are usually the largest single block of work. | Confirm which B2B features are live in production versus configured but unused, and scope only what customers use today. |
| Custom code and themes | Custom modules and overrides of Commerce-only classes must be rewritten or removed, and theme changes affect every storefront template. | Inventory custom modules, flag any that depend on Commerce classes, and retire dead code before the migration starts. |
| Number of integrations | ERP, payment, tax, shipping, and marketing connectors each need confirmation that they work without Commerce-only services or APIs. | List every integration with its owner and test it against the target release, not just the current one. |
| Hosting change off Adobe Cloud | Moving from Fastly and Adobe-managed infrastructure to self-managed servers means new build pipelines, a Varnish layer for full-page cache, search, queues, and monitoring. | Document the current cloud environment, then size and provision the target stack in a staging copy before cutover. |
| PHP and service version upgrades | The target release sets its own PHP, database, OpenSearch, Redis or Valkey, RabbitMQ, and nginx versions, and Adobe supports only listed combinations. Older extensions may need upgrades too. | Compare your current versions with the system requirements for your target release, and check extension compatibility before choosing the release line. |
| Test coverage and staging | Without automated or scripted tests, every extension and checkout path needs manual regression. Weak staging parity makes cutover risk harder to judge. | Build a checkout and order regression suite early, and keep staging close to production data volume and configuration. |
| Cost components and who is paid | Internal staff time, partner fees under a written scope, self-hosted infrastructure, and extension licenses each carry different costs. Infrastructure and extension renewals recur, while audit, rebuild, and cutover work is one-time. | Ask for line items per component, separate one-time from recurring costs, and name which extensions and their license terms are assumed. |
How the move differs by store size and starting point
A store that uses few paid features is usually the simplest downgrade. The main work is confirming that claim with evidence rather than assumption, because licensed modules and their data can be switched on quietly by configuration or by a past project. Once the audit shows that no Commerce-only module carries live data, the remaining effort is mostly removal, regression testing and confirming that the store runs on a supported Magento Open Source release.
- Module audit: list every enabled module and compare it against the Commerce-only features in your edition, then check the database for records they created.
- Removal order: disable, test and then delete modules one at a time so a failure can be traced to a single change.
- Release target: choose a supported 2.4.x line, since Adobe's lifecycle policy sets the end of regular support for each release.
- Hosting: if the store is already self-managed, the hosting stack changes little, but confirm the PHP and search versions listed in the system requirements for the target release.
- Regression scope: checkout, search, promotions and customer login usually cover most of the risk.
Before starting, ask your Adobe account team in writing which modules and licensed features are active on your contract.
A B2B store is the most demanding starting point. Company accounts, shared catalogs, negotiated quotes, purchase orders and requisition lists are paid features, and buyers may rely on them every day. Moving to Magento Open Source means replacing each of them with extensions, custom work or a process change, and some may have no open-source equivalent at all. The scope therefore grows from a module removal into a functional rebuild, with buyer workflows tested end to end.
- Feature inventory: map each B2B feature in use to its replacement, extension or custom build, and flag gaps early.
- Data mapping: company hierarchies, price lists and contract terms must survive the move and be verified against source records.
- Buyer workflows: test quote approval, purchase orders and reordering with real customer roles, not only administrator accounts.
- Integrations: ERP and credit systems that depend on B2B data need their own test plans.
- Extension risk: check each extension's release history and compatibility with the target version before committing.
Ask for a written gap list from any implementation partner before you agree a fixed scope, because the B2B gap determines the schedule more than anything else.
A store with many custom modules, overrides and third-party integrations starts from a different point. The core question is not which paid feature is used but which code depends on Adobe-specific behavior. Custom modules written against Commerce-only services, GraphQL mutations or cloud-specific configuration will need review, while code that uses only the shared Magento Open Source framework usually carries over with testing. Plan for a code review that separates these two groups before any removal starts.
- Dependency review: search custom code for references to Commerce-only classes, services and configuration.
- Override audit: list core class rewrites and plugins, since upgrades can break them in ways that are hard to see in a quick test.
- Security headers: if custom code injects scripts or styles, check it against the Content Security Policy behavior in current releases.
- Caching behavior: custom blocks that bypass full-page caching may need changes when the cache layer changes.
- Test coverage: automated tests are often thin for custom code, so budget for writing targeted regression tests first.
Ask the team doing the work to name which custom modules they expect to rewrite, retain or retire, and to justify each choice in writing.
Where the store runs today changes the infrastructure work more than the code work. A store on Adobe's cloud infrastructure uses services and configuration that do not exist in a self-managed deployment, including Fastly for full-page caching, while a self-managed store typically uses Varnish. Moving off Adobe's cloud means rebuilding the deployment pipeline, the cache layer, search, queues, backups and monitoring on infrastructure you control, then proving the new stack matches the old one under load.
- Deployment pipeline: rebuild build, deploy and rollback steps without relying on Adobe-managed tooling.
- Cache layer: Adobe documents Varnish for self-managed installations and Fastly for cloud-hosted Commerce, so cache rules must be re-implemented and tested.
- Service stack: confirm search, cache, message queue and database versions against the system requirements for your chosen release.
- Backups and restore: test a full restore on a separate environment, including media files.
- Load testing: compare response times and cache hit rates on the new stack with the production baseline.
Ask your hosting provider or internal platform team to document who patches each service, and how often.
What usually goes wrong and how to prevent it
Stepping down from Adobe Commerce to Magento Open Source keeps the same codebase, so most failures come from what gets removed, what changes in caching and security headers, and what was never tested. Each card names one risk and the check that prevents it.
Removing a Commerce module still in use
Commerce-only modules often sit behind code that other modules, themes or custom integrations still call. Removing one without a dependency search can cause fatal errors on checkout or in the admin. Before deleting anything, search the codebase and the composer dependency tree for every class and service the module provides, and run the storefront and admin end to end on staging after each removal.
Losing B2B data and pricing rules
Company accounts, shared catalogs, negotiated prices and requisition lists live in Commerce-only tables. A plain uninstall can orphan or drop this data, and customers may see list prices at checkout. Export every B2B record and price rule to a file, document the mapping to replacement extensions or custom code, and compare sample orders priced before and after the change.
Cache behavior changing from Fastly to Varnish
Cloud-hosted Adobe Commerce uses Fastly for full-page caching, while self-managed installations use Varnish. Cache tags, purge rules, TTLs and the ESI setup are not identical, so pages can serve stale prices or customer-specific blocks. Rebuild the Varnish configuration for your version, then test logged-in and logged-out pages, cart updates and cache purges on a copy of production traffic.
CSP settings blocking payment pages
Content Security Policy rules that worked on Adobe Cloud can block payment provider scripts and iframes once the store runs in your own infrastructure. From 2.4.7, CSP runs in restrict mode by default on storefront and admin payment pages, so a missing source domain fails checkout silently for some shoppers. Review the policy in the admin, list every payment, fraud and analytics domain your gateways load, and test each payment method in a browser console for blocked resources.
Unsupported service versions in the stack
Adobe supports only specific combinations of PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx for each release. Running a version outside the requirements list, or a database that is not on it, leaves the store without vendor support and can break indexing and sessions. Check the system requirements for your target release line before provisioning, and pin each service version in your infrastructure code.
Extensions without Open Source support
Many paid Adobe Commerce extensions and some third-party modules declare compatibility only with Adobe Commerce or with specific releases. Installing them on Magento Open Source may fail composer resolution, break at runtime, or receive no security fixes. Ask each vendor in writing whether the extension supports Magento Open Source on your target version, and keep a register of extension owners, licenses and patch status.
Cutover without a tested rollback
A downgrade changes the codebase, database schema and hosting at once, so a failed cutover is hard to reverse by code alone. Without a verified backup of the database and media, and a documented rollback path, teams often find the old store cannot be restored in the time available. Take a full database and file backup, rehearse the restore on a separate environment, and agree a go or no-go checkpoint with the business owner before cutover.
Questions buyers ask before moving off Adobe Commerce
How much does moving from Adobe Commerce to Magento Open Source cost?
The license fee goes away, but the work does not. Cost depends on how many Commerce-only features you use, how many custom and third-party modules need changes, the hosting you choose and the developers you pay to do the work. Your one-time costs are the audit, replacement extensions or custom code, removing Commerce-only modules, staging tests and cutover. Recurring costs are hosting, paid extensions, patching and developer time. Ask any quote to split these items and to state which Adobe Commerce features it assumes you need replaced. The cost gap narrows quickly if your store relies on B2B company accounts or Adobe's cloud services.
How long does a migration off Adobe Commerce take?
The timeline is set by the number of Commerce-only features in use, the number of customizations, and how many integrations must be retested. Stores with few paid features and a clean codebase move faster than stores with B2B workflows, custom checkout logic or many integrations. Plan time for the audit, extension replacement, removing modules, performance and security testing on staging, and a rehearsed cutover with a rollback plan. No duration is fixed in advance. Ask any implementation partner for a written scope and milestones before work starts, and confirm the cutover window with your own change process.
What does our internal team need to provide during the move?
Your team needs to own decisions about business rules and the people who can test them. Before work starts, you need a list of the Commerce features your store uses, access to the codebase and environments, catalog and order data samples, and the names of owners for payments, tax, shipping and ERP connections. During testing, business users must check pricing, promotions, B2B workflows if used, and order flows end to end. Your team also needs someone who can approve the hosting design and the security controls that replace Adobe's managed services.
Can our own developers do the migration without an outside partner?
Yes, if your developers have Magento 2 experience and time to test. The work is mostly code review, module removal, extension selection and infrastructure setup, which is familiar to an in-house Magento team. The risk lies in the areas that Adobe Commerce handled for you, such as Fastly caching, support for PHP and search services, and security headers. Teams that do the work alone should document each removed module, rehearse the cutover and confirm version support with Adobe's published requirements. An outside partner can take fixed-scope parts of the work, such as the hosting build or security testing, while your team keeps the store knowledge.
Will our custom code and extensions still work on Magento Open Source?
Most custom code written against the Magento 2 framework should carry over, because Adobe Commerce and Magento Open Source share one codebase. The exceptions are modules that depend on Commerce-only components, which must be removed or replaced before the move. Third-party extensions need to be checked against the exact Magento Open Source version you run, including its PHP and database requirements. Run your full test suite and the storefront and admin checks on staging before cutover. Confirm each extension's compatibility with its vendor in writing.
How do support and security patches differ after the move?
Adobe Commerce customers receive Adobe support, while Magento Open Source relies on community support and the patches Adobe publishes for the open-source codebase. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, with end of regular support on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Adobe's release schedule says security patches ship at least annually for all supported lines, and a full LTS patch ships each May. Confirm with Adobe which patches apply to your release line, and plan who applies them and how fast.
Which hosting services must we replace when leaving Adobe's cloud?
Self-managed Magento needs you to run the services Adobe otherwise operates. Adobe's system requirements for 2.4.9 list PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64. Adobe documents Varnish as the full-page cache for self-managed installations, while cloud-hosted Adobe Commerce uses Fastly. Confirm these versions and combinations with Adobe before you build the environment, since Adobe supports only the listed combinations.
Official sources for the migration
Before you schedule a downgrade, confirm the target version and its support window directly from Adobe. The Magento Open Source 2.4.9 release notes describe what the Open Source line includes, including the note that the clearCart GraphQL mutation, previously Adobe Commerce only, is now available in Open Source. Read that list against your own custom code and integrations, because a feature that moves into Open Source may let you delete a workaround module. The release notes also cite the PHP, Symfony and core fix counts for this release, which are useful for scoping regression testing, but they do not tell you which of your extensions still work, so those checks stay on your side.
The Adobe Commerce lifecycle policy sets how long each 2.4.x release receives standard support, and that window should drive your target version. Use the released versions page to confirm which patch level is current before you pin it, and the system requirements to confirm the exact PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx combination Adobe supports for that version. Adobe supports only the listed combinations, so a hosting plan built on an unlisted stack is a risk to resolve before cutover. Ask your hosting provider to confirm each component in writing.
The magento2 GitHub repository is the source for the code itself and its OSL-3.0 license, which applies to the Open Source distribution you will run after the move. Check the license file and the bundled AFL 3.0 terms with your legal team, and confirm whether any paid Adobe Commerce modules were installed under a separate agreement that must be terminated or removed. Keep copies of the release notes, lifecycle dates and requirements you relied on, with the access date, in your migration file so the decision can be reviewed later.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the move from Adobe Commerce to Magento Open Source is scoped in writing before any work starts. The work covers the code downgrade, extension replacement, hosting changes and testing, with ongoing support available afterward as a retainer.
How we scope
- Inventory which Adobe Commerce-only modules, B2B features and data sets your store actually uses before estimating work.
- Agree in writing which paid features need open-source extension replacements and which need custom development.
- Define the target hosting, including Varnish replacing Adobe's cloud Fastly layer, and the supported PHP, MySQL or MariaDB and OpenSearch versions.
How we build
- Remove Commerce-only modules on a staging copy, then confirm the Magento Open Source storefront, admin and checkout still run.
- Install and configure replacement extensions, and test each one against your catalog, customer groups and pricing rules.
- Set up Content Security Policy headers and cache, search and queue services in your own environment, then run load and regression tests.
How we hand over
- Deliver written runbooks covering the module removal sequence, configuration, rollback steps and cutover checklist.
- Document every replacement extension, its version, its license and the custom code you own after handover.
- Provide test evidence and security configuration records that your internal team or independent auditors can review.
How we support
- Offer retainers for ongoing patching, upgrades to later 2.4.x releases and extension compatibility checks.
- Plan upgrade windows around Adobe's published patch and end-of-support dates, which you should confirm for your version.
- Run continuous security testing of the storefront and APIs as an optional retainer after cutover.
