Moving Beyond Magento 2.3.5: Planning a Legacy Store Upgrade

Treat Magento 2.3.5 as a legacy upgrade topic

Magento 2.3.5 is an old release, not a recommended new deployment target. A store still using it needs a version-specific assessment of its code, extensions, data and supported upgrade path. Plan a staging migration and a recoverable cutover rather than applying old release instructions to production. Test commercial workflows after the upgrade, including search, payments, notifications and administrative tasks.

Inventory the legacy store before planning an upgrade

List the exact release, installed modules, custom theme, integrations and infrastructure dependencies. Identify which components have a supported update path and which need replacement. Catalogue modifications deserve particular attention because a migration may succeed technically while altering product relationships or storefront behaviour. Preserve a baseline export and document the business's most important order scenarios.

Create a staging plan with measurable acceptance conditions. Verify representative customers, products and orders, then test search, promotions, payments and fulfilment integrations. Plan how new production orders will be handled during the cutover window. A rollback needs more than restoring old code if data has changed in the meantime. Agree the decision point and recovery method before scheduling the live migration.

Plan Magento and Adobe Commerce work around the installed edition

Magento Open Source and Adobe Commerce are related but distinct products. Confirm the actual edition, version and deployment model before choosing an extension or following an installation guide. Requirements for PHP, search services, databases and other components depend on the supported release. Use the current documentation for that release rather than copying a command sequence written for an older environment.

Take a recoverable backup and work in staging for upgrades or structural changes. Inventory custom modules, themes, scheduled jobs and integrations, then check their compatibility. Keep file ownership aligned with the intended deployment and web-server users. Broad write permissions may hide an ownership problem while introducing unnecessary exposure; understand the expected access before changing it.

Validate the business journeys after deployment: catalogue browsing, search, basket updates, checkout, notifications and administrative operations. Check scheduled processing and indexing as well as the storefront. Document the exact changes and rollback conditions. A technically successful deployment can still leave the shop unable to process a particular product or payment method, so release approval needs evidence from the store's actual operating workflow.

Reduce operational risk with recoverable changes

Security work should begin with the systems and information the business depends on. Keep an inventory of websites, domains, hosting accounts, integrations and the people who own them. Remove unnecessary access, use strong authentication where supported and keep essential software maintained. A tool labelled secure cannot compensate for abandoned administrator accounts or an undocumented dependency.

Backups need a recovery plan. Decide what is included, where copies are stored and how often the data changes. Test restoration into an isolated environment and confirm that the recovered site includes both files and database content. Record the steps and the people who can carry them out. A backup job that reports success is useful evidence, but a successful restore is stronger evidence of recoverability.

For changes, keep a rollback path and avoid altering unrelated settings during an incident. Record the symptoms, recent deployments and relevant logs before attempting a repair. Restrict access to secrets and personal data during investigation. After service is restored, identify the cause and improve the process that allowed it. Clear ownership and tested recovery often matter more to a small business than an impressive list of tools with nobody assigned to operate them.

Plan store operations before increasing traffic

Marketing creates pressure on the fulfilment system. Before increasing traffic, check stock accuracy, shipping rules, customer-service capacity and the handling of unavailable items. Write down what happens when a payment succeeds but an inventory update fails, or when an order must be partially refunded. These cases are easier to resolve when responsibilities are clear before customers encounter them.

Confirm the sources of truth for stock, pricing and order status. If the store connects to an accounting or warehouse system, document the direction and timing of updates. Monitor failed synchronizations rather than assuming that an integration continues working because it succeeded at launch. Limit staff permissions to the tasks they need and review access when a role changes.

Prepare for seasonal demand with realistic tests. Check a promotion from advertisement to product page, discount application, payment and receipt. Make cut-off dates and delivery limitations visible wherever customers make a buying decision. Keep a rollback plan for a problematic extension or promotion. After the campaign, compare margin, returns and support workload with revenue so the business can distinguish profitable growth from a short-lived increase in order count.

Test checkout as a complete commercial process

Map the full order journey before evaluating checkout design. Customers need to know the total price, available payment methods, delivery choices and what happens after purchase. Unexpected charges or missing information can stop an otherwise interested buyer. Make the basket easy to review and avoid requiring an account unless there is a clear business reason.

Use the payment provider's test environment to cover successful payments, declines, cancellations and delayed confirmations. Verify how the store receives payment status, including server notifications, and how it avoids creating duplicate orders. Do not treat a return to the website as sufficient proof that money was received. Confirm that inventory, receipts and fulfilment use the same reliable order state.

Operational testing matters as much as the customer-facing screen. Process a refund, examine the order record and check who receives alerts. Review the experience on mobile and with the available accessibility tools. Keep card data within the supported payment integration rather than collecting it in an ordinary form. After launch, monitor failed orders and customer questions; a recurring request for help often identifies a problem that the checkout design has not explained clearly.

Measure outcomes with enough context to make a decision

Define the question before choosing the dashboard. A lead-generation site needs to distinguish qualified enquiries from spam, job applications and duplicate contacts. A shop needs to separate completed orders from abandoned checkouts and refunded purchases. Agree on these definitions with the people who process the results. Otherwise different teams can report apparently conflicting numbers while using different meanings of success.

Document important events, their triggers and where the data goes. Check that one completed action creates one event, including when a visitor reloads a confirmation page or returns from a payment provider. Keep personal information out of analytics events and URLs. Review mobile and desktop journeys separately when their behaviour differs, and label internal tests so they do not inflate results.

Use trends and business context rather than reacting to every short-term movement. A seasonal offer, a change in advertising spend or a broken form can all change conversion numbers. Note these events alongside the report. When testing an improvement, decide in advance what would justify keeping it and allow enough relevant activity to form a useful view. If traffic is limited, direct customer feedback and usability observations may explain the problem faster than an elaborate experiment.