When Magento Open Source is enough and when Adobe Commerce is needed
Magento Open Source is enough when the store needs core catalog, checkout and order handling, the team can carry its own patching, and none of the Commerce-only features are on the requirements list. Adobe Commerce becomes the better choice when the business needs content staging, returns (RMA) management, B2B selling, or Adobe's support and patch lifecycle. The license decision is therefore a question about features and support obligations, not about whether the store can technically run. Both editions share the same core code base, so the test is which gaps your business cannot tolerate.
Start by listing your requirements against the Commerce-only features. Adobe's content staging documentation describes staging as available only in Adobe Commerce, letting merchants schedule campaigns and content updates from a staging dashboard. Adobe's returns configuration documentation marks RMA management the same way. If your merchandising team runs timed promotions or your service desk handles returns through the platform, budget for the licensed edition or plan equivalent workflows yourself, and confirm the current feature list directly with Adobe. B2B needs are different: the Adobe Commerce B2B extension, magento/extension-b2b, adds company accounts, shared catalogs with company-specific pricing, negotiable quotes and requisition lists, and it is available for all supported Adobe Commerce versions.
Support is the other driver. Magento Open Source 2.4.9 was released in May 2026, and Adobe's lifecycle policy lists standard support for 2.4.9 until May 31, 2029. Licensed customers get Adobe Commerce on-call support and, on Cloud, Adobe will no longer maintain environments running unsupported versions from June 1, 2027. If your compliance program requires a named vendor for security patches and on-call escalation, the license is the control that provides it. If your team can absorb patching, test extensions after each release and accept community-level support, the free edition remains a viable path. Ask Adobe for the written support terms for your deployment model before you decide, and check that the hosting stack you need is supported on either edition.
Which edition fits which store profile
A single-brand consumer store with no scheduled campaigns, no B2B accounts and a standard order flow is the profile where Magento Open Source covers most of what the team needs. The core catalog, checkout, promotions, order management and GraphQL APIs ship in the OSL-3.0 codebase, and the 2.4.9 release notes show the clearCart GraphQL mutation moved into Open Source, so a store on the free edition is not missing that capability. The Commerce-only items that usually matter for this profile are not the ones in this tab.
- Core commerce is free: the catalog, cart, checkout and promotions sit in the open codebase, so licensing cost does not come from these features.
- Staging is not needed: content staging, which schedules campaigns from a staging dashboard, is an Adobe Commerce feature, so a store that edits pages live loses nothing here.
- Support windows still apply: Magento Open Source 2.4.9 has standard support until May 31, 2029, according to Adobe's lifecycle policy, so the team must plan its own upgrades on that line.
- Self-managed patching: without a license, the team or its partner handles patch selection and testing for each security release.
- Hosting stack: the open edition still needs PHP 8.5, MariaDB or MySQL 8.4, OpenSearch 3, RabbitMQ 4.3 and Valkey 9 on the 2.4.9 line.
Before deciding, confirm with Adobe whether any current Commerce module used by your storefront has a license dependency.
A store that runs timed promotions, seasonal landing pages or large content changes, and that handles returns through a formal RMA process, is where the Commerce-only features start to carry weight. Adobe's content staging documentation describes staging as exclusive to Adobe Commerce, letting merchants schedule campaigns and content updates from a staging dashboard. Adobe's returns configuration documentation marks RMA management as exclusive to Adobe Commerce as well. Neither feature is in Magento Open Source.
- Scheduled campaigns: staging lets content and campaign changes go live at set times from one dashboard, which replaces manual releases in the open edition.
- Returns (RMA): merchandise return authorizations are a licensed-only workflow, so an open-source store needs a custom build or a third-party extension to match it.
- Custom build effort: if the team chooses the free edition, it should price the build and test effort for a staging or RMA substitute as a separate line in the quote.
- Upgrade interaction: any custom staging or RMA work must be retested against each patch and minor release, which recurs on the support calendar.
- Support path: licensed customers get Adobe's on-call support during standard support, which matters when a campaign fails at peak time.
Ask the vendor to confirm which staging and RMA behaviors your current operations require, and compare that list against the open-source alternative you would build.
A merchant selling to businesses needs company accounts, negotiated pricing per buyer group and quote workflows. The Adobe Commerce B2B extension, magento/extension-b2b, is available for all supported Adobe Commerce versions and adds company accounts, shared catalogs with company-specific pricing, negotiable quotes and requisition lists. Adobe's B2B documentation presents these as part of the Adobe Commerce package, so this is the strongest case for a license.
- Company accounts: buyer organizations, roles and approval structures are provided by the B2B extension rather than by the open core.
- Shared catalogs: company-specific pricing depends on this feature, which is central to wholesale models.
- Negotiable quotes and requisition lists: these workflows are the reason many B2B teams license the platform, so confirm they match your sales process.
- Open-source route: a B2B build on Magento Open Source needs custom development or third-party modules, and the team must own their upgrade and security testing.
- Installation and version fit: confirm the extension's installation steps and compatibility for the exact release line you plan to run, using Adobe's B2B install guide.
Request a written scope from any partner that lists each B2B workflow you need, then compare the licensed feature set against the custom build.
Adobe's product solutions page says documentation badged PaaS applies to Adobe Commerce on Cloud and on-premises projects, and to self-hosted projects based on the Magento Open Source code base unless noted otherwise. Adobe's on-premises overview says that with on-premises Adobe Commerce the customer hosts and manages its own infrastructure, while Adobe supports the core application and provides Composer packages through authentication keys from the Commerce Marketplace. The hosting model, not only the feature list, separates the editions in this profile.
- Managed hosting: Adobe Commerce on Cloud is a licensed option where Adobe runs the environment, while Magento Open Source is always self-hosted by the team or partner.
- Enforced upgrades: from June 1, 2027, Adobe will no longer maintain Cloud environments running unsupported Commerce versions, under an enforced version upgrade policy.
- Cache layer: Varnish is the self-managed full-page cache, while cloud-hosted Adobe Commerce uses Fastly.
- On-premises licensing: on-premises Adobe Commerce still needs Marketplace keys for Composer packages, so plan access and rotation.
- Lifecycle dates: standard support for 2.4.9 ends May 31, 2029, and Adobe offers one extra year at no cost to customers on 2.4.6 and 2.4.7.
Confirm with Adobe which hosting option, support tier and cache design apply to your contract before comparing total run cost.
Which capabilities are Commerce-only
This table sets the capabilities documented for Magento Open Source against those documented for Adobe Commerce, the licensed edition built on the same code. Read each row as a question to put to your own shortlist: if a capability is on your must-have list, the Commerce column tells you where it is documented, and the note row tells you what to verify before signing.
| Capability | Magento Open Source | Adobe Commerce |
|---|---|---|
| Content staging (scheduled campaigns and content updates) | No | Yes |
| Returns (RMA) management | No | Yes |
| B2B extension (company accounts, shared catalogs, negotiable quotes, requisition lists) | Not applicable | Available for all supported Adobe Commerce versions (magento/extension-b2b) |
| clearCart GraphQL mutation | Available from 2.4.9 (previously Adobe Commerce only) | Available |
| Full-page cache in self-managed installs | Varnish, documented for self-managed installations | Varnish for self-managed; Fastly for cloud-hosted Commerce |
| Confirm before purchase | Check the current Open Source feature list in the 2.4.9 release notes | Confirm the current feature list and edition scope against Adobe documentation before purchase |
How licensing, support and updates differ
Magento Open Source is free to use under OSL-3.0, but the support clock, security patches and hosting options come from how you license and run the platform. The four cards below separate the code license from the commercial support Adobe sells, so you can check what each option actually includes before you commit budget.
OSL-3.0 open source core
Magento Open Source is licensed under the Open Software License 3.0, and the distribution also includes AFL-3.0 licensed components. Using the code does not carry a license fee, but it also does not carry Adobe's support commitments. Your legal team should review OSL-3.0 and AFL-3.0 terms alongside your third-party extension licenses, since many extensions carry their own terms. Confirm which extension licenses your store depends on before you rely on the free edition for a regulated launch.
Adobe Commerce as the licensed edition
Adobe Commerce is the commercial edition built on the Magento Open Source code base. The license is what brings Adobe-backed quality fixes, security patches and on-call support, plus Commerce-only features such as content staging and returns management. Ask Adobe in writing which deployment model your license covers, whether on-premises or Adobe-hosted cloud, and what the license fee and renewal terms include. Pricing is not set in this page, so request a quote tied to your store's scope.
Three-year standard support per version
Each Adobe Commerce version receives three years of standard support from its general availability date. That window covers quality fixes, security patches and Adobe Commerce on-call support for licensed customers. Free-edition users do not get this support from Adobe, so they carry the patching and upgrade work themselves. Plan your upgrade calendar around the end-of-support date of your current line, not the release date of the next one.
Extra year for 2.4.6 and 2.4.7
Adobe Commerce customers on 2.4.6 and 2.4.7 receive one additional year of support at no additional cost, according to Adobe's lifecycle policy. This is an extension for licensed customers only, so it does not change the free edition's position. Check whether your license and environment qualify, and confirm with Adobe how the extra year interacts with the August 2026 end date for 2.4.6 before you plan a migration freeze.
On-premises Adobe Commerce versus Adobe-hosted cloud
Choosing between on-premises Adobe Commerce and Adobe-hosted cloud is mostly a question of who owns the infrastructure and the upgrade calendar. With on-premises Adobe Commerce, the customer hosts and manages its own infrastructure, and Adobe supports the core Commerce application. Your team owns the servers, the search, cache and queue services, the patch window and the disaster recovery plan. Composer packages for Commerce are installed with authentication keys from the Commerce Marketplace, so the build pipeline needs those keys stored and rotated like any other credential. Before committing, confirm with Adobe exactly which extensions and third-party services fall inside its support boundary, since the support statement covers the core application.
Adobe-hosted Commerce on Cloud is a different operating model. Cloud-hosted Commerce uses Fastly for full-page caching, where self-managed installations use Varnish, as documented in Adobe's configuration guide. Adobe also states that from June 1, 2027 it will no longer maintain Cloud environments running unsupported Commerce versions, under an enforced version upgrade policy. Teams on Cloud should map their current version against the lifecycle policy and schedule upgrades well before that date, because the enforced policy removes the option of deferring an upgrade on your own timetable.
Self-hosting Magento Open Source has trade-offs that run in both directions. Adobe's product solutions page says documentation badged PaaS applies to Adobe Commerce on Cloud and on-premises projects and, unless otherwise noted, also to self-hosted projects based on the Magento Open Source code base. That makes shared documentation useful, but it does not mean Adobe supports Open Source in the same way it supports licensed editions. Teams that run their own infrastructure gain full control over hosting location and upgrade timing, but they also carry the operating burden of the Varnish, search, cache and queue stack, security patching and the yearly release work. Ask whether your internal team, or a partner, can own that load for the full support window you need.
What drives the cost of each edition
Magento Open Source is free to download under OSL-3.0, so its cost sits in hosting, implementation, extensions and upkeep. Adobe Commerce adds a license fee on top of those same components, and the cards below explain who is paid for what and what to request in a quote.
License fee for Adobe Commerce
Adobe Commerce is sold as a commercial license, and the supplied facts do not include a price, so the fee cannot be estimated here. Ask Adobe or an Adobe partner for a written quote that states the deployment model (on-premises or Adobe-hosted cloud), the number of stores or environments, and whether B2B and content staging are included. Confirm which fee recurs annually and which is one-time before comparing totals with Magento Open Source.
Hosting and required service stack
Both editions need the same core services: OpenSearch 3, RabbitMQ 4.3, Valkey 9 and MariaDB or MySQL 8.4 for 2.4.9. Self-managed installations also run Varnish as the full-page cache, while Adobe-hosted cloud uses Fastly. Your infrastructure team pays for these servers or cloud resources in both cases. Ask for a sizing estimate that lists each service, its redundancy and whether the license quote covers any of them.
Implementation and extension work
Standing up the store, theme, payment and shipping integrations, and data migration is paid as project work in either edition, usually under a fixed-scope agreement. Adobe Commerce adds features such as content staging, returns management and the B2B extension, which must be configured and tested as part of the build. Ask each vendor which extensions it has verified on your chosen version and who owns regression testing after go-live.
Ongoing patching and upgrades
Adobe patches Adobe Commerce under the lifecycle policy, which gives each version three years of standard support from general availability. Magento Open Source receives the same core security patches, but your team or partner must apply and test them on schedule. Plan a recurring budget line for patch cycles, extension compatibility checks and the major version upgrade due when support ends. Confirm in the quote which support tier and response times apply.
Team needed to run each
Magento Open Source needs an in-house or contracted team that can manage PHP, the search and queue services, caching, security configuration and upgrades. Adobe Commerce needs the same skills plus an Adobe relationship for licensing, support and on-call escalation. Ask what staffing level the vendor assumes, which tasks are included in the support contract, and whether your own engineers would be the first responders for incidents.
Cost components for each edition
This table sets out the cost components for self-hosting Magento Open Source and running Adobe Commerce, and marks which costs are one-time and which recur. No prices are published in the supplied facts, so use it to shape what you ask for in a written quote from Adobe and from implementers, not to estimate totals.
| Cost component | Magento Open Source | Adobe Commerce |
|---|---|---|
| Software license | No license fee. Source is licensed under OSL-3.0, so the code itself is free to use. | Paid commercial license from Adobe. Confirm pricing, term and renewal terms in writing with Adobe or a reseller. |
| Support | No vendor support contract. Security and quality fixes come from the open-source release cycle, and any paid support is bought from a third party. | Standard support for each version (three years from general availability) includes quality fixes, security patches and on-call support. Confirm what your contract covers. |
| Hosting | Self-hosted in your own infrastructure. You pay for servers, cloud accounts or data center capacity and their operation, recurring. | On-premises or Adobe-hosted cloud. On-premises carries the same infrastructure cost as Open Source. Adobe Cloud pricing is a separate quote to request. |
| Required services | PHP, MariaDB or MySQL, OpenSearch, RabbitMQ, Valkey or Redis and nginx for 2.4.9. You install, patch and monitor each one, recurring. | Same core stack for on-premises (PHP 8.5, MySQL 8.4 or MariaDB, OpenSearch 3, RabbitMQ 4.3, Valkey 9). Full-page caching uses Varnish when self-managed, Fastly on Adobe Cloud. |
| Implementation partner work | One-time build, theme and integration work, plus recurring retainers if you need them. Scope and effort are set by your written scope. | Similar build work, often with added effort for licensed features such as staging and returns. Ask implementers to price each feature separately. |
| Extensions and B2B setup | Third-party extensions usually carry their own license and recurring fees. B2B features must be built or sourced separately. | Commerce-only features such as content staging and returns management are included with the license. The B2B extension (magento/extension-b2b) is available for supported Adobe Commerce versions, so confirm its terms in your quote. |
| Upgrade effort | Recurring. You apply the annual full patch cycle and security patches yourself or through a partner, and test extensions with each release. | Recurring. Plan around standard support windows and the enforced version policy for Cloud from June 1, 2027. Upgrade testing and partner time recur with each version. |
Moving from Open Source to Adobe Commerce, or back
The sequence confirms that the Commerce-only features and support window justify the license, then moves a store onto a matching Adobe Commerce build with its staging and returns settings tested before cutover. The reverse path is a separate project with its own checks.
Confirm the features and support window you need
The commercial team and the store owner list which Commerce-only capabilities the business needs, such as content staging and returns (RMA) management, and which B2B features, such as company accounts, shared catalogs and negotiable quotes, come through the B2B extension. Compare that list against the Adobe Commerce lifecycle policy for the version you plan to run. Confirm the standard support end date for the target release line and whether any Cloud environment on an unsupported version falls under the enforced upgrade policy. This step is done when the written requirements and the chosen version are signed off by both the business owner and the technical lead.
Check PHP, database and search versions for the target
The platform team compares the current stack with the system requirements for the target release, including PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, Composer and nginx. Adobe supports only the listed combinations, so any server that falls outside them must be upgraded before the install. Confirm the Varnish version on self-managed hosts as well. This step is done when a written compatibility matrix for the current and target stacks has been reviewed, and every gap has an owner.
Obtain the license and Marketplace keys
For an on-premises install, the license holder obtains the Adobe Commerce license from Adobe or its reseller, and the engineering lead generates the Commerce Marketplace authentication keys that Composer needs to pull the packages. Store the keys in the secrets manager, not in the repository. Confirm with Adobe which entitlements apply to the store, including support contacts and any hosting option the license covers. This step is done when a test Composer install authenticates successfully from the build server.
Install the matching Commerce package on a staging copy
The DevOps team builds a non-production environment from the matching Adobe Commerce package on the chosen release, and then restores the Magento Open Source database and media into it. Install the B2B extension only if the business has confirmed it needs those features, and apply the same patch level that production will run. Compare the module list, theme compatibility and custom code with the Adobe release notes, and log every extension that fails to install or needs a change. This step is done when the staging site loads the storefront and admin without errors and the install log is reviewed.
Migrate and test content staging and RMA settings
The merchandising team rebuilds the scheduled campaigns and content updates in the staging dashboard, and the operations team reproduces the returns (RMA) configuration, including reasons, statuses and the order workflow. Test each scheduled change against a clean copy of the data and check that a campaign published on a set date shows the expected content at the expected time. Record which settings cannot be carried over from Open Source, since those must be rebuilt by hand. This step is done when each campaign and return path has a passed test case and a named approver.
Switch caching and page delivery to the hosting model
The platform team plans the cache layer for the new setup. On self-managed installs, Adobe documents Varnish as the full-page cache accelerator, so the Varnish configuration must be tested with the new release. On Adobe-hosted Cloud, Adobe uses Fastly instead, so the existing Varnish rules are retired and Fastly is configured. Verify Content Security Policy headers in both the storefront and payment pages, since the policy is in restrict mode by default from 2.4.7. This step is done when the page cache hit rate and the payment page headers have been checked in the staging environment with production-like traffic.
Run the cutover and keep the rollback path open
The release manager schedules a cutover window with the business, freezes content and order changes during the final sync, and runs the production migration from the tested build. Keep the Magento Open Source environment and its database backup available until the store has run through the first full order and return cycle on Commerce. Confirm monitoring and support contacts before go-live. This step is done when the store has processed live orders, scheduled content has published on time, and the rollback plan has been formally closed by the business owner.
Plan the reverse path if the license is dropped
Moving from Adobe Commerce back to Magento Open Source is a separate project. The team removes Commerce-only modules such as staging and RMA, checks whether any data created by them must be exported or rebuilt, and reinstalls the open-source package with its matching stack. Staging schedules and returns records will not carry over automatically, and the B2B data needs its own review. Confirm the Magento Open Source support window for the target version before committing, since the open-source line follows its own release dates. This step is done when a written plan lists each feature being removed and each data set being moved, with an owner for each.
Questions buyers ask before choosing an edition
Can a store run on Magento Open Source alone?
Yes, a store can run on Magento Open Source alone, because the code is licensed under the Open Software License 3.0 (OSL-3.0) and carries no license fee for the software itself. The README describes it as delivering basic ecommerce capabilities for building an online store. The gap is in the features Adobe reserves for Adobe Commerce: content staging for scheduled campaigns and returns (RMA) management are documented as exclusive to Adobe Commerce. The B2B extension (magento/extension-b2b) is also an Adobe Commerce package. If your roadmap does not need those features, Open Source can be the right base. Confirm with Adobe which features your business case depends on before you commit, because the feature list is the deciding factor, not the code license.
What drives the license fee and implementation cost?
The software license fee for Adobe Commerce is set by Adobe and sits outside the Open Source code, so it is a recurring cost you should request in writing. Implementation cost is driven by a different set of factors: the number of integrations (ERP, payment, tax, shipping), custom themes, extensions, catalog size, the hosting model and the number of environments. Adobe Commerce on premises means you host and manage your own infrastructure, while cloud-hosted Adobe Commerce is a separate operating model. Both paths carry hosting and operations costs. Ask Adobe for a written quote that separates the license, the hosting model, support and any B2B or staging entitlements, and ask your implementation partner for a fixed-scope statement of work that lists each integration and environment.
How long does a move from Open Source to Adobe Commerce take?
The duration depends on scope rather than on a standard timeline, so no figure can be given here. The main drivers are the number of Commerce-only features you adopt (staging, returns, B2B), how much custom code and how many extensions must be checked against the Commerce feature set, the number of integrations to re-test, and the data you migrate. Your target version also matters: Adobe's lifecycle policy gives each Adobe Commerce version three years of standard support, and the 2.4.9 line has standard support until May 31, 2029, so a version chosen now sets your upgrade calendar. Ask for a written plan that lists each phase, the test cycles and the cutover window before accepting a schedule.
What does the work need from our internal team?
Plan on an internal team that can own the hosting stack, the upgrade cycle and the business rules that the store encodes. Magento Open Source and Adobe Commerce 2.4.9 require PHP 8.5, MariaDB or MySQL 8.4, OpenSearch 3, RabbitMQ 4.3 and Valkey 9, and Adobe supports only the listed combinations. Self-managed installs use Varnish for full-page caching, so someone must own cache configuration, search indexing and queue workers. Each patch cycle, security patch and annual full patch needs testing against your extensions and themes. Ask Adobe which support tier covers on-call help and which responsibilities stay with your team on premises.
Can our own developers do the migration without a partner?
Your developers can do it, but only if they have hands-on experience with Magento's architecture, Composer-based builds, the service stack listed in the system requirements and the Adobe Commerce upgrade path. Many teams underestimate the testing load. A realistic check is whether the team has run a version upgrade and a staging-based release in production, and whether it can rebuild the search, cache and queue services from scratch. If those skills are thin, a fixed-scope engagement with a partner such as DeployOpen can plan, implement, integrate, harden and document the move, with the scope and deliverables agreed in writing before work starts. DeployOpen does not issue audit reports or certifications for the result.
When is the B2B extension worth paying for?
The B2B extension is worth evaluating when your sales model needs company accounts, shared catalogs with company-specific pricing, negotiated quotes or requisition lists. Adobe documents that the extension is available for all supported versions of Adobe Commerce and adds these capabilities. If your business sells one price list to individual consumers, the extension adds cost and operating complexity without matching value. If you sell to contracted accounts with different prices, the extension can replace custom code that would otherwise need upkeep through every upgrade. Ask Adobe to confirm the licensing terms for the extension and how it is covered under your support tier.
How DeployOpen scopes an edition decision
DeployOpen plans, implements, integrates and supports self-hosted Magento Open Source inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For an edition decision, that means the work starts with a written statement of which Commerce-only capabilities you need and which ones you can do without. Content staging, returns (RMA) management and the B2B extension each change the build, the data model and the operating load, so they belong in the scope document rather than in a later change request. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins, so an edition question should be answered at that stage, not during build.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move the number are the ones you should define up front: the number of storefronts and languages, the B2B account and catalog rules, the integrations with your ERP, payment and tax systems, the hosting model you choose, and whether you want ongoing support or a retainer after go-live. Ask for the quote to separate one-time work (planning, migration, customization, hardening, documentation) from recurring work (upgrades, patching, testing), and to state which licenses or Adobe fees, if any, are outside DeployOpen's estimate. Those license costs are paid to Adobe, not to DeployOpen, and they must be confirmed directly with Adobe.
DeployOpen is not an Adobe partner, reseller or certified provider. If you choose Adobe Commerce, the license, the Commerce Marketplace authentication keys and the support terms come from Adobe, and DeployOpen can implement against them but cannot sell or vouch for them. Before you sign a scope, confirm with Adobe which lifecycle dates apply to the release you plan to run, using the Adobe Commerce lifecycle policy, and record the answer in the scope. That single check often decides whether a store can stay on a supported line through its planned life.
How DeployOpen delivers either Magento edition
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. The same method applies whether the store runs Magento Open Source or a licensed Adobe Commerce, with the edition choice and its license terms settled in the written scope before any build work starts.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope records which edition you run, and which Commerce-only features, such as content staging or returns management, are in or out.
- Scope also covers hosting target, required PHP, MariaDB or MySQL, OpenSearch, Valkey and RabbitMQ versions, and whether the B2B extension is needed.
How we build
- We install, configure and customize the platform inside your infrastructure, including cache, search and queue services.
- Extensions, integrations and any Adobe Commerce B2B extension are tested against the exact version combination in your scope.
- Security hardening, including Content Security Policy configuration, is tested before the store moves toward production.
How we hand over
- Deliverables include architecture documentation, runbooks for upgrades and backups, and records of configuration decisions.
- Upgrade and rollback procedures are written for your own patch cadence and your team's skills.
- Handover sessions walk your engineers through operating the store, so knowledge stays with your organization.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can track the lifecycle dates for your chosen release line, so upgrade planning starts early.
- Ask us to confirm which support obligations sit with Adobe, which sit with DeployOpen and which sit with your team.
