Magento upgrade partners for heavily customised stores, ranked for 2026

scandiweb is the only company on this page that takes all five components of the heaviest criterion here. Its Magento upgrade services page opens the process with an audit rather than a version number, and states that the first thing a merchant receives is a written compatibility verdict, dated and sequenced, listing every module that will break on 2.4.9. The audit itself is itemised, covering the current version, custom code, extensions, integrations and hosting, and it produces a scope and a timeline before any work begins. The outcome for a module that will not carry forward is stated rather than implied: modules that break on a new release are refactored as part of the upgrade, abandoned extensions are replaced with maintained ones, and extension and custom-code refactoring is published as a service line of its own. It also publishes the rule for when an in-place upgrade is the wrong answer, that anything from 2.4.3 upward is a version upgrade, that below 2.3 the frontend usually needs rebuilding alongside the core, and that Magento 1 is a replatform rather than a version bump, handled through its Magento 2 migration practice. That is 24 of 24, and one other company here matches it.

On rollback and cutover it takes the full 16. The upgrade is built on a full staging copy while production keeps running untouched, go-live happens inside a planned window with a rollback path ready on every release, and the recovery time is published: if anything looks wrong, the store is rolled back to the previous version in minutes rather than fixed on live traffic. The Magento support page repeats the pattern for ordinary releases, stating that changes go live in a controlled release with a rollback ready. A named case study puts a length on the window rather than leaving it abstract, an 8-hour coordinated launch with half of it spent on the data import alone. Of the six companies on this page that promise zero downtime or zero data loss, scandiweb is the only one that also publishes what happens if the promise fails.

Cost and duration take the other full 16, and this is where the 12-point gap to second place mostly comes from. The upgrade page carries a table: a security patch cycle at one to two weeks against a typical market figure of $1,000, a version upgrade to 2.4.9 at two to six weeks against a typical market range of $15,000 to $35,000, and a Magento 1 replatform from $35,000. The dollar figures are published as what agencies charge across the market rather than as scandiweb's own quote, with its own column reading fixed after audit and, for retained clients, free. The durations are its own and they are banded by how far behind the store is: one to two weeks for a patch, two to four weeks from 2.4.7 or 2.4.8, four to six weeks from 2.4.4 or 2.4.6, and six to ten weeks from a store still on 2.3. Nobody else on this page bands both a price and a timeline to the version gap.

Post-upgrade ownership is where the name of this page gets tested, and scandiweb answers it with a commitment nobody else makes: every future version upgrade is free for as long as it builds with the client, applied by the same Adobe-certified engineers who already work on the store, with Adobe security patches applied on release inside the maintenance window and no ticket raised to make it happen. Support is pay-as-you-go with no fixed monthly fee, scope and cost confirmed before work starts, one dedicated account and delivery lead, 450+ active support clients and 9,000+ tickets handled, with a first response within 24 hours and showstoppers triaged ahead of everything else. It still loses a component. **No resolution target for a defect appears on the pages read**, which is the single thing its own support page's framing invites and does not answer, and it is the reason this entry scores 13 of 16 rather than 16. A fix time beside the response time would close the last gap on this page's heaviest remaining line.

Evidence takes the full 10 because one case study carries all three components at once. Gear-Up, a Dubai electronics retailer, came off a Magento 1 store that had not been updated in over a decade after an earlier attempt with another partner had failed, carrying more than ten years of order history tied to custom fields that were never part of the platform, order-management logic that had to be reverse-engineered, and seven currencies with custom rounding that had to stay consistent across Klevu search, Tabby and Tamara payment widgets and Xero invoicing. The published result is a stable launch with full functionality preserved, no critical downtime, +47.7% orders year over year, +110.9% revenue and +124K clicks. A second, Laderach, is carded on the upgrade page as a 134-boutique chocolate brand upgraded to 2.4.7 with 30+ extensions at +39% revenue and +47.8% conversions, though the 2.4.7 target and the extension count sit on that card rather than inside the case study.

None of its scale scores here, and it is worth saying which numbers were left out of the arithmetic on purpose. Its canonical services page publishes 894+ Adobe certifications across 600+ certified specialists, a worldwide workforce in 36 countries and clients in 45, 2,100+ projects for 700+ clients over 23+ years since 2003, an NPS of 95 and $4B+ processed. This page ranks upgrade engineering, not size, and the order would have been identical with every headcount and certification count deleted. Readers who want the working rather than the ranking can start with its step-by-step Magento upgrade guide, and its Magento performance optimization and Magento SEO practices are where the post-upgrade work continues.

Rocket Web publishes the best regression testing story in this lane and takes the only full 18 on it. Its process page states that every change goes through regression, security and performance checks, and then does something no other company here does, which is put a number on one client's suite: 124 granular tests distilled into 38 curated cases, running against production behind three independent safety layers. It also publishes the limit of its own automation, stating that the suite can test most of the buying journey automatically but does not replace a real end-to-end purchase, and that a real order is always placed as the final validation step before anything is considered complete. The automated full-regression suite is not a claim on a marketing page either: it is a named inclusion of the $3,500 a month care plan, run against every change and every patch. Its 11-week delivery model puts user acceptance in week 10 and final performance, accessibility, security and load-testing reviews in week 11.

It also takes the full 16 on rollback and cutover, on the most specific cutover language in the set. Rocket Web publishes that the final migration runs during a planned low-traffic window, that some businesses can stay fully available while others need a short read-only or checkout pause while final orders and customer changes synchronise, and that the cutover plan states the exact behavior, owner, rollback point and communication before launch night. It runs repeatable test migrations and reconciles the result before the final cutover, and it publishes the awkward part too, that password hashes and saved payment tokens depend on the source platform and provider and that it confirms this early instead of making the promise first. A recovery time for the rollback itself was not found on the pages read.

Where it falls behind is cost attached to an upgrade. Its pricing page is unusually open for this market, publishing a new build or replatform from $49,500, Hyva frontend modernization from $25,000, rescue and recovery from $3,500 and four monthly care plans at $3,500, $5,500, $9,500 and $14,500, with fixed quotes after assessment and new requests pushed into a later phase rather than into the invoice. But an upgrade is explicitly scoped as a fixed-price project with no published band, and platform and extension upgrades carry a price only as an inclusion of the $5,500 plan, so this criterion takes 8 of 16. On ownership it matches scandiweb at 13, publishing 30 days of stabilization after launch, security patches applied within five days of release, next-business-day urgent response, same-business-day emergency response, and a portability commitment worth reading in full: the client owns the repositories, data, infrastructure accounts, deployment access, documentation and test suite, and if the relationship ends the documentation and access do not become leverage. No resolution target was found on the pages read.

On evidence its three components sit in different places, which is why it takes 7 rather than 10. THKStore names Magento 1 Enterprise to Magento 2 Commerce B2B with multiple custom modules and a November 2019 launch, and publishes its results as prose with no figure. GopherSport publishes seven measured before-and-after numbers, including HTTP requests down from 359 to 90 and Core Web Vitals moving from failed to passed after custom functionality was carried across, and names no version pair. Rocket Web also states its own partner position candidly, that it holds Hyva Silver and Shopware Gold, belongs to the Mage-OS Association, and left the Adobe Solution Partner programme after more than a decade because the recommendation should follow the requirement rather than a licence. No tier scores anything here.

LitExtension, a shopping cart migration company with a Magento upgrade service, publishes the clearest module triage in the lane and matches scandiweb's full 24. One sentence on its upgrade page does what most agencies spend a section avoiding: the assessment identifies which parts can be upgraded, which should be replaced and which should be retired. Around it sits the most itemised audit inventory read anywhere for this page, covering the exact source version, edition, installed patches, deployment model, hosting environment, software dependencies, store views, extensions, themes, custom modules, APIs, integrations and data volume, alongside business-critical flows including search, accounts, checkout, payment, shipping, tax, promotions, order management and administrative operations. Where a module is no longer maintained it publishes four possible outcomes, replacement, refactoring, redevelopment or removal, and it documents the agreed technical scope, data scope, testing responsibilities, deployment plan and project-specific exclusions before execution. It publishes the in-place-is-wrong position as a section of its own, that a clean-store rebuild may be better where the store has accumulated unsupported extensions, difficult dependency conflicts, outdated custom code, unnecessary records or a planned redesign, and states that Magento 1 cannot be converted by a routine Composer update at all. It takes the full 18 on testing, naming functional, regression, data, performance and security checks, then listing fourteen areas they can cover, stating that automated checks and manual review are both used, and ending in merchant user acceptance. It takes the full 16 on rollback and cutover on the strength of a published rollback plan, rollback conditions named inside the upgrade plan, a controlled cutover window, and a pre-launch review that itemises outstanding issues, deployment steps, content and configuration freezes, recent-data synchronization, maintenance requirements, traffic changes, rollback conditions and post-launch checks. It is also the only company on this page that refuses the industry promise, stating that it does not describe every project as zero downtime because actual downtime depends on architecture, data-change volume, integrations, infrastructure and the final synchronization plan, and that the objective is to minimize disruption without guaranteeing something the implementation cannot support. Then it stops. On cost and duration it takes 4 of 16, because it states outright that there is no reliable universal duration for a Magento version upgrade, and neither a figure nor a range was found on the page read, only a 30-day money-back guarantee in its service table and a promise of a scope-based timeline after assessment. On ownership it takes 6 of 16 on 30 days of support after completion for eligible projects and a 24-hour response time commitment, with no continuing owner named. On evidence it takes nothing: no named client, no version pair and no measured outcome for upgrade work was found on the page read. That is how a company can publish the best engineering language in a lane and still finish third.

Customer Paradigm, a Boulder agency working since 2002, publishes the most concrete idea on this page and gives it a name. Its upgrade page states that a store may not be upgrade safe, and explains why in plain terms: if the original developer did not build the theme and custom features properly, the upgrade will not survive contact with them. It follows that with a practice, not a slogan, examining the existing code base before providing a quote so nobody is surprised after the project starts, and its emergency support page describes the instrument, a quick code review file that reports within moments what version of Magento is running, what core files have been modified and what extensions are installed. That is a real audit inventory, and modified core files is the item every other page in this set leaves out. Extension work is stated as an outcome as well, upgrading existing extensions, installing a newer version where the vendor has shipped one, or troubleshooting the ones that are not compatible. It takes 19 of 24, missing only a written compatibility document before work starts, since what the merchant receives is a quote. On testing it takes 14, and the method is the most specific in the set even though it fits the ladder awkwardly: a dedicated testing team compares the live site to the development site page by page to confirm the upgrade is 100% functional, with the stated acceptance condition that the job is not done until the site has the same feel and functionality the old one did, and go-live waits for sign-off by both the testing team and the client. Its 30-step quality assurance process, published for support work, names SSL security, page load time, contact form submission and checkout cart functionality. What was not found on the pages read is any mention of automation, and that costs it the fourth component. A named senior developer also publishes the upgrade mechanism itself, walking through how Magento compares the schema version in core_resource against the module version in config.xml and runs the matching upgrade scripts, warning that up to 60 upgrade scripts may run across modules and that the database step can take anywhere from 10 minutes to several hours. It is the only genuinely technical upgrade writing on any page read for this ranking, and it is also visibly old: its worked examples are Magento 1.6 and it links the retired magentocommerce.com wiki. From there the page thins out. Rollback and cutover takes 4 of 16 on a database dump into a development database, with no window, no rollback plan and no recovery time found on the pages read. Cost takes 4 of 16: firm quotes are promised and the first hour is free on a five-hour commitment, with no minimums, and no rate, no range and no project duration was found on the pages read. Ownership takes 6, on the most personal commitment in the set, the name, email address and direct contact details of the project manager and the developer in charge, and on an hourly model running from one hour to a thousand. Response is described as quick, prompt and within moments, never as a number. Evidence takes nothing: the named work published is 3M, Xcel Energy and a Travelocity accessories shop, none of them a Magento upgrade, and the only upgrade count is a developer stating he has done 15 in the past year.

Meetanshi sells the Magento upgrade as a product with a price on it, and that alone makes it the most commercially transparent entry on this page. It takes 12 of 16 on cost and duration, three of four components, and the third one is the interesting one: the version selector on its upgrade page prices the work by how far behind the store is. From a Magento 2 source the surcharge runs +$80 from 2.4.x, +$280 from 2.3.x, +$520 from 2.2.x, +$760 from 2.1.x and +$1,000 from 2.0.x; from a Magento 1 source it runs from nothing at 1.9.x up to +$1,020 at 1.3.x, with an annual upgrade service offered at +$900. The listed price on the page as read was $299, and the page's own product data carries $279; both figures are recorded here with where they sit, and neither is presented as the other. Delivery is published as less than a week. No binding commercial term beyond the listed price was found on the page read. It also publishes the most version-explicit portfolio anywhere in this ranking, which is why its evidence line scores at all: ten named live stores with the source and target printed beside each, including poolpro.co.uk, drywalltoolsdirect.co.uk and penhouse.in from 2.2.6 to 2.4.4, three aironboard domains from 2.4.1 to 2.4.7-p4, otpclothing.com from 2.4 to 2.4.7-p3, mudmayhem.ca and hipenchic.nl from 2.3 to 2.4, and allemotoronderdelen.nl from 2.3 to 2.4.7-p2. Not one of the ten carries a measured outcome, so it takes 4 of 10 rather than more: it publishes the two components that prove the work happened and not the one that says what it was worth. Its published six-step process is where the engineering criteria catch up with it. Store audit and backup, compatibility check, staging upgrade, QA and bug fixing, deployment after final approval, then 30 days of free support is a defensible sequence, but the compatibility check names only the theme and the extensions, with custom code, integrations and hosting not found on the page read, and no outcome is stated for a module that cannot carry forward, so it takes 9 of 24. Testing is a QA team meticulously testing every aspect with no areas named, which is 9 of 18 on the stage and the approval gate alone. Rollback takes 4 of 16: the upgrade runs on a secure staging server and a backup is taken at step one, and no window, no rollback plan and no recovery time were found on the page read. Ownership takes 6 on the 30-day cover period and the priced annual upgrade option, with high priority support claimed and no number attached to it. A reviewer on the page writes that a 2.0.14 to 2.2.1 upgrade was done in three days, which is a testimonial and is not scored as a delivery time.

Onilab publishes the upgrade lane as a Magento 1 to Magento 2 migration and takes 19 of 24 on it, four of five components, on the strength of one step most competitors skip entirely. Its store audit has each specialist evaluate the current store from their own angle, frontend, backend and integrations, listing code bottlenecks and examining extensions and third-party plugins. Its extensions step states the outcome properly: where third-party functionality has to be kept, Onilab either selects a substitute among Magento 2 solutions or configures and customises the existing one. And then it publishes wireframing as a compulsory stage whose purpose is documentation rather than design, stating that wireframing makes sure 100% of store functionality, including every feature and every interaction, is documented so the business logic can be recreated, ending in functional documentation with the final wireframes. For a buyer whose actual fear is that an upgrade quietly drops a workflow nobody wrote down, that is the most directly relevant published practice on this page. It also says out loud that skipping the step is why many merchants arrive having already had a bad migration. A published position on when an in-place upgrade is the wrong answer was not found on the pages read. Cost and duration take 8 of 16 on two components: a project range from $7.7k to over $100k, and a duration of around four to six months with cases delivered in two to three, though nothing is banded by version distance and no binding commercial term was found. Where it falls away is control of the switch. On rollback and cutover it scores nothing. The published stages run preparation, predeploy procedures and migration execution, ending in rolling out the store and releasing the finalized version, and no staging or development copy, no go-live window, no rollback plan and no recovery time were found on the pages read. That is the widest gap between method and mechanics in this ranking, and it matters more here than the money does. Testing is a single list item, testing out the solutions, which is 5 of 18. Ownership takes 3: the support page states 24x7 Magento support and maintenance, 50+ support experts and 40+ clients serviced regularly, and describes the process as a form, a call, an NDA and a price quote, with specialists on standby who react instantly. No response figure, no cover period and no resolution target were found on the pages read. Evidence takes 4 on two named projects with real numbers, GSM55 with 40,000 products and 2.5 million customers migrated, 10+ custom extensions and 5+ third-party modules carried across, deployment downtime reduced to zero seconds and a 55% mobile conversion increase, and VapeMate with a 37% organic traffic gain, an enterprise ERP integrated and mobile load time cut threefold. Neither card prints a version pair, which is the component the page's own subject would have made easy.

Wagento publishes a genuine commercial commitment and a thinner engineering one. Its budget guarantee is stated plainly, that the price quoted upfront is the final price paid, with no surprise charges and no last-minute add-ons, and it offers a free performance report so a merchant knows what the store needs before committing. With a typical upgrade published as taking anywhere from a few days to a few weeks, that is two of four components and 8 of 16 on cost and duration, with no figure and nothing banded by version distance found on the page read. On custom code it takes 14 of 24. A compatibility assessment is named, outcomes are stated for what breaks, with extension harmony for essential extensions, theme revamp covering either upgrading the existing theme or finding a new one, and API and payment fixes for breakage, and the free performance report is the deliverable a merchant receives before committing, with the page stating that the right target version depends on extension compatibility and PHP requirements assessed during it. What is missing is the itemisation: extensions, themes, integrations and custom features are all promised compatible, but no audit inventory naming version, custom code, integrations, hosting and data was found on the page read, and the contents of the section headed The Magento Upgrade Service Process were not found in the served HTML of the page read, so whatever that graphic carries is not counted against it or for it. Testing takes 5 of 18 on a quality assurance audit described as a thorough post-migration checkup, with no areas named, no automation and no sign-off gate found. Rollback takes 4 of 16, and this is the clearest case on the page of a promise outrunning a plan: zero downtime and no data loss are both published as headline commitments, the store is stated to stay online throughout, and no window, no rollback position and no recovery time were found on the page read. Ownership takes 3 of 16 on one component, that Wagento does not disappear after launch and provides ongoing and post-upgrade support as an extension of the team, with training and documentation included. No cover period, no response figure, no priced plan and no resolution target were found. Evidence takes 2: Hyde Park Jewelers, SERRV International and Bus Depot are named, but only inside testimonials, and the one that mentions an upgrade is a client writing that the migration to Magento 2 happened with virtually no downtime, which is a customer's words and not a published position. Wagento states 14+ years of Magento experience with a copyright line running from 2009, and lists Hyva among its partners. No tier scores anything here.

Plumrocket, an extension vendor with a services arm, publishes the single most useful paragraph in this whole ranking and almost nothing to price it with. It takes 19 of 24 on custom code, four of five components, and two of them are unusual. The first is a named list of what actually breaks, published as the most frequent issues during a 2.4.7 upgrade: the serializer change from PHP serialized format to JSON, the WYSIWYG editor failing to save because of a JavaScript file, database issues during backup related to rewrites, third-party modules erroring because Magento changed its core classes and methods, and Braintree not working correctly afterwards. No other page read for this ranking names a defect at all. The second is a published recommendation against its own sale. Plumrocket states that it sometimes does not recommend upgrading as soon as a release lands, because third-party vendors need time to make their products compatible, that with a lot of such extensions the more rational choice is to wait for their updates, and that the alternative is having Plumrocket update the third-party code for an additional fee. Its seven-step process guarantees that existing third-party extensions and customisations made by previous developers will work properly afterwards, with conflicting plugins and code updated. A written compatibility deliverable before work starts was not found on the page read; what is published is a quote after a website analysis. After that the page runs out of specifics fast. Testing is one step, final tests and fixes to eliminate issues in the customer shopping journey, which is 5 of 18. Rollback takes 4 of 16: a development environment is set up because the upgrade is never performed on the live site, and a backup of database and files is taken before upgrading, and no window, no rollback plan and no recovery time were found on the page read. Cost and duration score nothing at all, the only zero on that line: pricing is published as varying with the number of conflicting third-party extensions and the version being upgraded from, which is a pricing basis rather than a price, and no figure, no range, no duration and no binding term were found on the page read. Ownership takes 3 on an account manager assigned to each project, with full ongoing support and maintenance offered after the migration on no published terms. Evidence scores nothing: a customer success stories block exists but its case study titles did not render in the served HTML of the page read, and the four large brand names that appear in prose carry no case study URL beside them, so they are recorded and not used. Plumrocket publishes 18+ years in business, a footer running from 2008, 150k+ Magento stores using its extensions and clients in 165 countries.

BelVG publishes the fastest response figure anywhere in this ranking and finishes ninth, which is the clearest illustration of what this page measures and what it does not. Its migration page states that the project manager responds within 1-2 working hours and is available at all times for urgent matters, and its support page adds that clients are informed about new security patch releases within 24 hours and that BelVG works to get updates and the latest patches applied within 72 hours. That is two and a half times faster than the best first-response figure published by the company at the top of this page. It takes 10 of 16 on ownership, three of five components, on that response figure, on direct communication with developers including daily comments and Git commits, and on continuing access to Magento updates and patches after launch. The fifth component still eludes it as it eludes everyone: no resolution target was found on the pages read, and the nearest text, under first priority response, describes getting problems fixed within several minutes as something the response allows rather than something BelVG commits to, with no severity and no scope attached. Everything upstream of the response time is thinner. Custom code takes 9 of 24: extensions are reviewed and Magento 2 counterparts chosen, with ready-made replacements or custom development offered, and integration compatibility is reviewed before work starts, but no audit covering custom code or hosting, no written deliverable before work starts and no position on when an in-place upgrade is wrong were found on the pages read. Testing takes 5 of 18 on one stage, double check before going live, which names extensions and integrations and then other tools, two areas short of the three this page counts. Rollback and cutover score nothing: no staging or development copy, no go-live window, no rollback plan and no recovery time were found on the pages read, on a page that states no data will be lost. Cost takes 4 of 16 on one genuinely unusual commercial term and nothing else: BelVG states that its team will not exceed the maximum time estimate provided and that the first payment is only required after two weeks of work, which is the only deferred-payment position published by anyone in this ranking. No price and no duration were found. Evidence takes 2: BelVG states it supports over 100 online stores in more than 15 countries with lead developers of 10+ years supervising each project, its related projects are labelled by platform and country only, and the named companies on the page, eCommerceSense, Artipoppe, Silent Disco King and Blaha Gartenmoebel, appear inside testimonials with no version pair and no figure.

MageAnts publishes one thing better than most of the companies above it and very little else. Its upgrade timeline table bands the work by source version and names the work inside each band: 2.4.x to 2.4.8 in 7 to 11 days covering extension fixes, payment issue fixes, PHP and server updates, testing and deployment; 2.3.x to 2.4.8 in 10 to 13 days covering theme and extension compatibility, Composer updates, search fixes and payment fixes; and 2.2.x to 2.4.8 in 12 to 15 days covering a full upgrade, a theme and extension rebuild, a server upgrade and bug fixing. With an overall figure of 7 to 15 working days stated separately, that is two of four components and 8 of 16 on cost and duration, with no price figure and no binding commercial term found on the page read. Testing takes 9 of 18 on the stage and on a scope naming four areas, checkout, payment, extensions and performance, tested before go-live, with automation and a merchant sign-off gate not found on the page read and manual expert review published as a labelled panel. Custom code takes 5 of 24, one component: extension compatibility and fixes, custom feature compatibility and theme compatibility are all named as inclusions, and no pre-upgrade audit step, no audit inventory, no written deliverable and no position on when an in-place upgrade is wrong were found on the page read. The contents of the section headed Our Magento Upgrade Process were not found in the served HTML of the page read. Rollback and cutover score nothing, on a page whose hero promises zero data loss, full backup protection and minimal or no downtime, and which describes a zero downtime upgrade approach as a structured process without naming staging, a window, a rollback position or a recovery time. Ownership takes 3 on 30 days of post-upgrade support, with the client retention rate published as a tile that carries no figure. Evidence scores nothing: 80+ Magento upgrades delivered, 80+ global team members, 9+ years, 1K+ projects and 19+ Magento certified developers are counts, and no named upgrade client, version pair or measured outcome was found on the page read. Two things on the page are checkable by anyone who opens it and worth knowing before a call. The target release throughout, in the hero and in all three rows of the timeline table, is 2.4.8, on a page dated 2026, while 2.4.9 has been generally available since May 2026. And the tab labelled 2.4.8 Version in the what's new block opens on text about a different release, beginning that Magento 2.4.6 improved many platforms.