Magento Upgrade Services

It depends almost entirely on the extensions and custom code, not on how many versions you are behind. A reasonably standard store with a handful of well-maintained extensions is a matter of weeks including testing. A heavily customized store with abandoned modules can be a lot longer, and the audit is what tells the two apart. We would rather give you a number after looking than before.

We don't publish a price, because the number depends on things we can only see by looking at the store. What moves it: how many versions you are skipping, whether PHP has to move too, how many third-party extensions you run and how many still have a maintained release, how much custom code there is and whether it uses Magento's extension points or edits core, whether you have a staging environment, and whether the theme is Luma, Hyvä, or something custom. A store with a dozen maintained extensions and clean custom code is a much smaller job than one with forty extensions and a theme nobody has touched since 2019. The audit is where the number comes from.

Upgrade, almost always, if you are on Magento 2. A Magento 2 store is upgraded in place — the data, the catalog, the URLs, and the order history all stay. A rebuild only makes sense when the custom code is so extensive or so badly done that migrating it costs more than rewriting it, and even then it is usually a partial rebuild of the theme or a handful of modules, not the store. Magento 1 is the exception: moving to Magento 2 is a rebuild with a data migration attached, whatever anyone calls it.

Eventually, because security patches stop being released for a version once its support window closes, and a store that cannot be patched is a store waiting to be a news story. But the timing is a business decision and there is usually more room in it than a vendor countdown suggests. We will tell you where you actually stand.

Each one gets checked for a compatible release. Where there is one, it comes along. Where the vendor has gone quiet, the options are replacing it with something maintained, rebuilding the part of it you actually use, or taking on maintaining it yourself — and we will tell you what each costs before you pick.

Each one is checked against the new core: deprecated classes, changed interfaces, plugins on methods that no longer exist, and the places where a module was copied from core and never updated. Modules built inside Magento's extension points usually need small changes or none. Modules that override core classes wholesale are where the time goes, and where we will suggest moving to a plugin on a narrower target so the next upgrade is cheaper than this one.

There is a maintenance window for the deploy, usually short and scheduled when your traffic is lowest. The work before it happens on a staging environment, not on your live store.

Sometimes, and it is a question to ask — if your Magento version supports a newer PHP than you are running, that is a smaller job with a real security benefit. More often the two are tied together, and doing them separately means doing the testing twice.

Yes. The upgrade itself is the same work. What is different is the deployment — the application and services configuration, the build and deploy hooks, and the Fastly configuration in front of the store — and that it has to run through Cloud's own pipeline on an integration or staging environment before it reaches production.

No, and the distinction matters: Magento 1 to Magento 2 is a rebuild with a data migration attached, not an upgrade. It is scoped and priced differently. If a rebuild is not this year's project, OpenMage LTS keeps a Magento 1 store on supported PHP and getting security fixes in the meantime.