Define the purpose and the target
Start with the reason for the upgrade. The business may need to maintain support, address patch requirements or prepare the platform for further development. A clear purpose helps distinguish the necessary platform work from optional design and functionality changes that might otherwise expand the project without a separate decision.
The target needs to be specific to the current edition and deployment. Magento Open Source, Adobe Commerce and different hosting arrangements do not all follow an identical operating process. The proposal should identify the source and target releases, the assumptions behind that route and the information still needed to confirm it.
At Midoriweb, we check the relevant requirements during scoping rather than naming a universal latest version in a proposal template. Your store's extensions, customisations and supporting services need to be considered against the actual target. That gives the upgrade a technical basis your business can review.
Build an inventory of the implementation
An upgrade plan should account for the components that make the store work. That includes the theme, third-party extensions, custom modules, connected systems and the hosting services involved. The inventory does not need to be a catalogue of every file, but it must identify the meaningful dependencies and their owners.
Ask who can explain the customisations and provide access to their source. A feature may have become part of daily operation even if nobody remembers why it was built. That does not make it safe to remove. The assessment should establish its purpose and whether the target release requires it to change.
Include the operational processes outside the storefront. Imports, exports, scheduled tasks and order transfers can be critical to trading while remaining invisible in a visual website review. Their implementation and expected behaviour belong in the scope. Where documentation is missing, the proposal should state the discovery needed instead of treating the gaps as confirmed compatibility.
Separate compatibility work from optional improvement
The platform update may require changes to extensions, custom code or the theme. Those are part of delivering a usable upgraded store. A new design, a different checkout feature or a wider catalogue reorganisation may be worthwhile, but each introduces another set of decisions and checks.
We recommend identifying those categories in the scope. The business can then see which work is necessary for the target release and which work is an additional improvement. That distinction makes the proposal easier to assess and allows optional changes to be scheduled without obscuring the core upgrade.
Supplier dependencies should be visible too. An extension may need a compatible release or an answer from its developer before the route can be confirmed. The proposal should explain what is known, what remains dependent on another party and how that uncertainty affects the plan. A clear dependency is more useful than a confident estimate built on an unsupported assumption.
Review the environment as well as the application
Magento's supported component requirements depend on the exact release. PHP, database, search, caching and other services need to be checked against that target. The plan should identify who can make the necessary changes and whether the hosting arrangement supports them.
The test environment also needs attention. If it differs materially from live, the project should explain how those differences will be handled during testing and release. An upgrade that works in one environment does not automatically establish that the same deployment will behave identically elsewhere.
Our server management service can deliver relevant environment work or coordinate it with your hosting provider. The important planning point is ownership: application and hosting responsibilities should meet in one release plan, with the required actions agreed before the upgrade is ready to deploy.
Define acceptance around real store activity
Acceptance should describe the functions the business needs after the upgrade. A page loading and an Admin login succeeding are useful checks, but they are not a complete account of a trading store. The test scope should follow relevant customer and staff journeys.
Examples include browsing representative categories, selecting product options, using search, applying the business's pricing rules and completing checkout through suitable test facilities. Staff may need to create or update products, process orders, run imports and review the output of scheduled jobs. Integrations need checks on both sides of the connection where their behaviour is affected.
Include the less common scenarios that matter commercially. A particular customer group, delivery destination or product combination may be a small part of total traffic but essential to a valuable workflow. The people running the store can help identify those cases and confirm the expected outcome.
The record should distinguish checks completed from checks not performed or limited by the available environment. That information supports an informed release decision. It also provides a useful starting point if a problem appears later, because the business can see what evidence existed at the point of acceptance.
Agree the release and recovery plan
The release plan sets out the sequence for applying the upgrade and the conditions for opening the store to normal use. It should identify responsibilities, access, backups, any maintenance window and the checks required after deployment. The business needs to understand the trading implications before choosing the time.
Recovery arrangements must reflect the actual changes. Restoring application files is different from reversing database changes or reconciling transactions created after a release. The plan should explain the practical recovery route and the circumstances in which it would be used. It should also state who can authorise that decision.
We connect this planning with the implementation itself. The relevant configuration and deployment steps are rehearsed where possible, and the release record states what happened and what was checked. This allows the business to assess a completed deployment from evidence rather than from the fact that the installation command finished without an obvious error.
Keep the scope and responsibilities readable
A useful proposal should make the work understandable without requiring the business to design the upgrade. Look for the current and target state, compatibility work, environment requirements, testing and release responsibilities. The proposal should also identify exclusions and assumptions that could change the scope.
The commercial arrangement needs the same clarity. Discovery and implementation may be separate stages when the current store contains unknowns. Larger changes identified during assessment should be explained before they are added to the project. The business should be able to see how an unresolved technical question affects the next decision.
Communication during delivery should focus on meaningful progress and choices. A compatibility issue has a practical implication; a test result supports a release decision; a provider dependency needs an owner. At Midoriweb, we connect updates with those purposes so the project remains understandable to the people responsible for the store.
Plan what happens after the upgrade
The upgraded store still needs maintenance and further development. The handover should identify the components changed, custom patches retained and any follow-up tasks. It should also explain the responsibilities for monitoring the initial period after release and handling findings that arise.
This is an opportunity to make the store's technical record more useful. The next developer or support request should not have to reconstruct the upgrade from memory. Version information, relevant dependencies and the checks performed provide a basis for future work.
Our ongoing Magento support can maintain that continuity, with the included tasks and availability agreed around the business's needs. A separate support relationship is not assumed automatically; it is a defined option for keeping maintenance and development connected after the upgrade project ends.
A short readiness check for the business
Before scheduling the final release, confirm that the people responsible can answer the following questions. The answers can be brief, but they should refer to the actual project and its evidence rather than a general process description.
- Has the target release and its supporting environment been confirmed against the current implementation, including extensions and custom code?
- Have the staff responsible for products, orders and integrations reviewed the relevant upgraded workflows and recorded unresolved issues?
- Is the deployment sequence understood by everyone who needs to contribute, including hosting or other external providers?
- Are the required backups and recovery access available, with a clear decision-maker if the release cannot be accepted?
- Does the business know which checks happen immediately after deployment and who reviews the first period of operation?
- Is there an agreed owner for remaining actions, documentation and the maintenance work that follows the upgrade?
If an answer is missing, use it to identify the next preparation task. This keeps the launch discussion focused on readiness and responsibility.
How Midoriweb delivers Magento upgrades
Our Magento upgrade service brings assessment, development and release work into a coordinated scope. We review the current implementation, identify compatibility requirements and implement the agreed changes. Our Magento skills cover custom modules and themes, while our infrastructure and integration expertise addresses the supporting systems.
We work with your team to identify the business journeys and operating tasks that need to pass. Those requirements guide the testing and review points. When another provider needs to contribute, we coordinate the technical detail and keep the dependency visible in the plan.
The deliverable is the upgraded implementation, a record of the work completed and an account of the checks and remaining actions. We can also assist with an upgrade that has already failed, starting with the current state and the recovery options. The scope is built around the store and the outcome your business needs.
FAQs
Should we combine a redesign with an upgrade?
It can be appropriate, but the work should remain distinguishable. A redesign introduces its own requirements and acceptance checks. We can help assess whether combining the work or separating it into stages better fits the business's priorities.
What if we do not have complete documentation?
The assessment can identify and fill important gaps. The proposal should state that discovery work and explain how it affects the implementation, rather than assuming undocumented features are unimportant.
Can we upgrade without changing hosting?
That depends on whether the current environment can support the target requirements. We review the actual configuration and provider capabilities before recommending a change or confirming that the existing environment is suitable.
What should we send Midoriweb first?
Share the store address, current edition and version if known, the reason for the upgrade and any important custom features. Existing extension or hosting information is useful, but you do not need to assemble a complete technical inventory before the conversation.
Plan the next release with Midoriweb
Book a consultation or tell us about the upgrade you need. We will help establish the assessment, development and release work required for your store, with a scope your business can understand and review.
