Migration to Adobe Commerce from Magento Open Source: acceptance and portability

The store has been migrated and the catalogue opens, but a dealer sees the retail price, while a repeated request creates an extra order in the accounting system. That is why migration to Adobe Commerce from Magento Open Source should end not with a demonstration of the new cloud environment, but with verification of trading operations. Before work begins, agree who will confirm the accuracy of prices, payments, stock levels and purchase history, and how the business will obtain its data and code for its next migration.

You need the exact name of the target product, business acceptance scenarios and a cutover rehearsal. An agency ranking cannot replace any of these documents.

First establish exactly which cloud offering you are accepting

The name Adobe Commerce Cloud is not precise enough. Adobe Commerce on cloud infrastructure is platform as a service (PaaS), while Adobe Commerce as a Cloud Service is software as a service (SaaS). Here we consider Magento Open Source → Adobe Commerce on cloud infrastructure. SaaS requires a different plan.

Adobe’s official comparison of the models describes shared responsibility for PaaS: Adobe manages the hosting platform, while the merchant is responsible for application patches, custom code, configuration and supported dependencies. In SaaS, Adobe manages the core and its updates; the core code cannot be modified, and extensions are built through supported interfaces and services. An existing PHP module should therefore not automatically be assumed suitable for both models.

Record the product, model, applicable versions and purchased capabilities: licences and B2B extensions must be confirmed separately. If all you need is more reliable hosting, assess improvements to your existing Magento Open Source setup.

Turn the promise that “everything works” into business acceptance criteria

Business acceptance criteria describe the expected outcome in operational terms. For every critical action, specify the input data, steps, expected state in the store and the connected system, the person responsible and the evidence required. A video of a successful checkout is not enough if it does not show what the payment service, accounting team and warehouse received.

Test rules, not just pages

For the catalogue, the relationships between product variants, sales units and customer groups matter. For pricing, check currency, tax, rounding, discounts and customer-specific terms. For an order, check its contents, total, payment, stock reservation and fulfilment status. Add a failure case to every successful scenario: an unavailable product, an expired offer, a payment error or an unavailable accounting system.

Classify defects by their consequences. An incorrect amount charged, another customer’s individual price or a duplicate order must block launch. A non-critical visual flaw can go on an agreed list of follow-up work if it does not prevent a purchase. Agree this distinction before testing, not on the last evening before cutover.

Assign an owner to each sign-off

Sales checks commercial rules, the finance team checks amounts and refunds, and the warehouse checks stock reservations and dispatches. The technical team confirms that failures can be reproduced and resolved. The acceptance record needs results and outstanding limitations, not a collective “no objections”.

Separate data migration, the change of edition and module compatibility

Compile a module register: which business action each module supports, where it stores data, whether it is supported and what will happen if it is disabled. Pay particular attention to pricing, checkout, shipping and data exchange with the ERP — the enterprise resource planning and accounting system.

Data reconciliation goes beyond the total record count. An identical number of products does not prove that their variants, attributes and photo associations have been preserved. Check customer groups, addresses, historical orders, return documents and internal integration identifiers separately. For data you are not migrating, agree how it can be found in the archive and who is responsible for access.

Adobe’s upgrade recommendations include checking themes, extensions and dependencies, as well as user acceptance testing. Automated compatibility analysis does not check agreements with dealers: you need specific test orders.

Do not add an optional redesign or replacement of the accounting system: this will make failures harder to diagnose. Put shared dependencies in an infrastructure readiness plan for cloud migration.

Hypothetical example: an order confirmation is lost between the store and the ERP

Consider a hypothetical spare parts store with dealer-specific prices. A customer orders two packs of a product, while the accounting system tracks it by individual units. The integration sends the agreed quantity and the ERP creates an order, but the response never reaches the store. This is a training scenario for acceptance testing, not a description of a GL.ua client or result.

Simply repeating the request can create a second document. The agreed outcome is different: the integration uses a stable operation identifier, checks the status of the first request and links the website to the document already created. This behaviour does not arise simply from moving to the cloud: it must be implemented or verified in the existing data exchange. If the ERP does not support the required check, the team must agree on another mechanism to prevent duplicates.

In the test, record the order identifier, dealer price, conversion of packs to individual units and stock reservation status. Deliberately interrupt the response and repeat the action. Acceptance is complete when there is no extra document or stock reservation, the amounts match, the customer has received a clear status and the manager can see how to resume processing. Also test cancellation: it must not leave a hidden stock commitment in the warehouse.

Check a late payment notification too: who changes the order status, and on the basis of what confirmation? A “Thank you” page does not prove that the entire chain has completed.

Rehearse cutover with defined stop conditions

A rehearsal tests the sequence and duration of the work using your data. Adobe’s guide to deployment to Staging and Production provides for pre-production testing. The test environment must not charge real money or send test messages to customers.

1. Record the source state: code version, configuration, a reference set of records and a list of active data exchanges.
2. Perform a trial migration and reconcile not just records, but also the complete order flow, failure, return and repeated request scenarios.
3. Check the final data update: which changes have accumulated since the trial import and how they will reach the target.
4. Agree when to stop writes and switch integrations so that the old and new stores do not accept incompatible changes simultaneously.
5. Reproduce a critical failure and the rollback decision: who makes it, what is restored and how new transactions are reconciled.
6. After the test opening, check test purchases, data exchange logs, background jobs and the people responsible for on-call support.

For rollback, define the point beyond which simply restoring the old database is no longer enough. If the new store has already accepted a payment, restoring an old copy will not cancel that payment by itself. You need a procedure for reconciling these operations. This is one reason not to accept a promise of “one-click rollback” without a rehearsal.

A separate SEO check covers URLs, redirects, canonical tags and indexing. The website migration plan for preserving SEO has a broader checklist; assign someone to verify it.

Prove portability by restoring the store, not by handing over an archive

Online store portability means being able to reproduce the required data and behaviour in another agreed environment, taking licences into account. It does not mean that licensed Adobe Commerce features can be run free of charge in Magento Open Source or another CMS. If the business plans to leave, each such feature needs a replacement or a separate solution.

Include the repository with its change history, a list of dependencies and usage rights, deployment configuration, integration descriptions, the schema of custom tables and a data export procedure in the handover package. Transfer access credentials through an agreed secure channel, rather than recording them in the documentation. The business owner must control the organisation’s accounts, the domain and the right to appoint another provider.

According to Adobe’s backup documentation, a snapshot does not contain code, and a copy of it cannot be downloaded. It is not a ready-made exit package. Separately verify the export and restoration of the database, media files and code in accordance with your plan and environment type.

Have another authorised specialist recreate the test environment and find the required order without guidance from its creator. Errors uncovered by this exercise will become specific handover action items.

Estimate timelines and budget based on unknown dependencies

The duration depends on access to the source code, the state of modules, data volume and quality, integration complexity and the business teams’ involvement in testing. Plan discovery, adaptation, trial migration, fixes, a repeat rehearsal and launch as separate stages. Refine the cutover date after a timed trial run, not solely on the basis of the number of products in the catalogue.

Break down costs into licences and cloud services, audit and design, module adaptation, data cleansing and migration, integrations, SEO checks, test environments, business acceptance, launch and support. The parallel-running period and preparation of the exit package must be separate line items. This makes it clear which costs will end after launch and which will become recurring expenses.

Do not pay to migrate unnecessary features. If the advantages of the target edition are not linked to a business scenario you need, postpone the migration.

The launch decision must be based on evidence

Open the store after the scenarios have passed, critical defects have been resolved and the handover package has been checked. The recovery plan must account for new transactions. This is a controlled transition, not a guarantee of incident-free operation.

Considering a different architecture? Share your trading rules, integrations and portability requirements with GL.ua (Глянець). As part of Drupal website and online store development, discuss the alternative and scope of work before signing a migration contract.