47 Custom Modules. 23 ERP Integration Points.
Upgraded from 2.4.2 to 2.4.8 Without Breaking a Single One.
A UAE-based manufacturing and distribution company ran their entire B2B order management through a heavily customised Magento 2.4.2 store. Two previous agencies had attempted the upgrade and failed. Both caused partial outages that disrupted ERP sync and cost the client days of manual reconciliation. They came to us with a specific requirement: upgrade it, or don't start.
Why Two Agencies Failed Before Us — and Why This Upgrade Was Genuinely Hard
This was not a standard Magento upgrade. Over 4 years of active development, this store had accumulated 47 custom modules built by 3 different development teams, many of which had been modified directly without proper documentation. Several core Magento files had been overridden rather than extended — a pattern that makes version upgrades dangerous because the override logic must be manually reconciled with every new core release.
The ERP integration was the most complex piece. The store connected to a SAP Business One instance via a custom middleware layer, synchronising purchase orders, inventory levels, customer-specific pricing tiers, and shipment tracking across 23 separate API endpoints. The previous agency's upgrade attempt had broken 7 of these endpoints by modifying the API response format during the upgrade without mapping the downstream impact on the middleware.
The client's business operated on a 24-hour order fulfilment cycle — B2B customers expected to place orders before 3pm and receive warehouse confirmation by 9am the next day. Any disruption to the ERP sync broke this cycle, triggering manual reconciliation work that their operations team estimated at 14–18 person-hours per incident.
What the previous agencies got wrong — and what we did differently
Both previous attempts treated this as a standard Magento upgrade: update composer, resolve conflicts, deploy. Enterprise stores with deep ERP integrations require a fundamentally different approach — every API endpoint must be mapped, every custom module must be tested in isolation before integration testing, and the upgrade must be designed around the integrations, not the other way around.
We Spent 3 Weeks on Audit Before Writing a Single Line of Upgrade Code
Our first and most critical decision was to refuse to start the upgrade until the audit was complete. Both previous agencies had begun the upgrade process within days of being briefed. We told the client it would be 3 weeks of audit work before any upgrade code was written. They pushed back. We held the position.
The audit produced a 94-page Technical Migration Specification that documented every custom module, every core override, every API endpoint, every data dependency, and every potential conflict between the current codebase and Magento 2.4.8. It also explained exactly why the two previous upgrade attempts had failed at the code level — something no one had done before.
| Risk Category | Items Found | Risk Level | Resolution Strategy |
|---|---|---|---|
| Core file overrides | 14 files | Critical | Rewrite as plugins/preferences — eliminate overrides entirely |
| Deprecated API methods | 31 occurrences | Critical | Map each to 2.4.8 equivalent before upgrade execution |
| ERP endpoint compatibility | 7 of 23 affected | Critical | Rebuild response mapping layer, test with SAP sandbox |
| Vendor module compatibility | 16 modules | High | 11 updated versions available · 5 rebuilt natively |
| Custom pricing logic | 3 rule engines | High | Full regression test suite built before upgrade |
| Database schema changes | 8 custom tables | Medium | Migration scripts written and tested on data copy |
| PHP 8.1 compatibility | 23 occurrences | Medium | All deprecated functions replaced before upgrade |
| Frontend compatibility | Blank theme | Low | Minor CSS/JS updates — no structural changes needed |
The 8-Phase Upgrade Process That Made It Work
Weeks 1–3: Technical Audit & Migration Spec
Full codebase analysis, dependency mapping, API contract documentation, risk categorisation, and 94-page Migration Specification. Identified exactly why both previous upgrade attempts failed — deprecated method calls in the ERP middleware that neither agency had mapped.
📋 Deliverable: 94-page Technical Migration SpecificationWeeks 4–5: ERP Integration Rebuild
Before touching Magento, rebuilt the 7 affected ERP middleware endpoints using the Magento 2.4.8 API contracts. Created a SAP Business One sandbox environment mirroring the production ERP. Tested all 23 integration points against the new API layer. Achieved full ERP compatibility before the first line of Magento upgrade code was written.
⚡ Critical step: ERP rebuilt BEFORE Magento upgrade — not afterWeeks 5–6: Core Override Elimination
Rewrote all 14 core file overrides as proper Magento plugins and preferences. This was the most labour-intensive phase — each override had to be analysed for intent, rewritten using the correct extension pattern, and tested in isolation. This step alone took 80+ hours but eliminated the root cause of every previous failed upgrade attempt.
🔧 14 core overrides → 0 core modificationsWeek 7: Magento 2.4.8 Upgrade on Staging
With ERP rebuilt and core overrides eliminated, the actual Magento version upgrade ran cleanly. Resolved 31 deprecated API method calls across the custom module codebase. Updated 11 vendor modules to their 2.4.8-compatible versions. Rebuilt 5 vendor modules where no compatible version existed. PHP upgraded to 8.1 alongside Magento.
⏱ Core upgrade execution: 6 hours on stagingWeeks 8–9: Integration Testing & QA
Built a 340-item test script covering: all 23 ERP API endpoints, all custom pricing logic scenarios, role-based access control for 6 customer tiers, checkout flow with 4 payment methods, order fulfilment workflow end-to-end, and admin operations. Ran the full test suite 3 times before signing off. Zero failures on final run.
🧪 340-item test suite · 3 full runs · Zero failures on final passWeek 10: Client UAT + Staff Training
Client's operations team ran their own user acceptance testing against staging for 5 business days. Identified 4 minor UI issues in the admin order management workflow — all resolved within 48 hours. Conducted training sessions for admin users on new Magento 2.4.8 features relevant to their workflows.
✅ 4 UAT issues found and resolved · All stakeholders signed offWeek 11: Production Go-Live
Scheduled go-live for Friday 11pm local time — lowest order volume window of the week. Maintenance window: 3 hours. Ran final delta sync of any new orders/customers created during staging period. Deployed to production, ran live ERP sync test, placed test orders through all 4 payment methods. All 23 ERP endpoints confirmed active. Store live at 1:47am — 1 hour 47 minutes ahead of schedule.
🚀 Live 1hr 47min ahead of schedule · Zero rollback · ERP sync confirmedBefore & After — What Actually Changed
📈 Measurable Impact — 3 Months Post Go-Live
What Enterprise Magento Upgrades Require That Standard Upgrades Don't
The audit is not optional
Both previous failed attempts skipped proper auditing. The 3-week audit we required was resisted by the client — it ended up being the reason the upgrade succeeded where two others failed.
ERP integrations must be rebuilt before the upgrade, not after
Rebuilding the middleware before upgrading Magento meant the upgrade ran clean. Doing it the other way around — as both previous agencies did — guarantees integration failures.
Core file overrides must go
Every direct core file modification is a future upgrade blocker. Eliminating all 14 overrides in this project means this client can upgrade to every future Magento version cleanly. The 80-hour investment pays off forever.
A test suite is a permanent asset
The 340-item test suite built for this project now runs before every deployment. It has caught 3 regressions in the 3 months since go-live — none reached production.