Neil Boughton
Neil leads platform architecture and integration strategy at iWeb. He has designed ERP and commerce integration patterns across manufacturing, wholesale and retail, and writes about operational resilience, release governance, observability, and the infrastructure decisions that determine whether large programmes stay stable under pressure. Bias toward durable, measurable systems over architectural theatre.
- Notes published
- 26
- First note
- 31 Aug 2024
- Latest note
- 25 Jun 2026
- Contributing since
- 2024
- Platform architecture
- Magento
- Adobe Commerce
- ERP integrations
- Performance
- Delivery
- Managed support
- Platform quality
Everything Neil has filed.
When to keep Magento 2 past end-of-life: a defensible position, not a default one
Staying on an end-of-life Magento 2 is usually a high-risk error. But in rare cases, like a major acquisition or critical ERP migration, it can be a deliberate strategic choice if managed with extreme prejudice and a fixed deadline.
Replatforming without a freeze: the dual-write pattern that makes it possible
Conventional wisdom dictates a lengthy code freeze for any major replatform. We argue this is a costly mistake. This article explains the dual-write pattern, a strategy that keeps old and new systems in sync, eliminating the need for a freeze.
The real cost of a release freeze, calculated honestly
The release freeze is the most under-priced line item in most enterprise programmes. A practitioner method for putting a real number on it.
Why PIM should often come before the ecommerce rebuild
Addressing Product Information Management (PIM) before an ecommerce replatforming project mitigates risk, improves data quality, and can accelerate time-to-market.
ERP-led pricing in B2B commerce: SAP, Microsoft Dynamics and the integration patterns that survive
Synchronous pricing calls to the ERP are the most common avoidable failure in B2B commerce. The integration patterns that survive at scale decouple the storefront from the back office.
Ecommerce technical discovery: what should be checked early
Proactive technical discovery is key in ecommerce projects, moving beyond functional requirements to scrutinise system architecture, integrations, and data fidelity.
Adobe Commerce support: what good looks like after launch
Post-launch Adobe Commerce support is critical for ongoing stability and growth, shifting from reactive fixes to proactive maintenance and strategic evolution.
The difference between custom and careless
Customisation is a powerful tool in Adobe Commerce, but without clear governance, it can lead to technical debt and operational burden. Careful planning is needed.
When Shopify, BigCommerce or commercetools are the right answer
When evaluating commerce platforms, Shopify, BigCommerce, and commercetools represent valid alternatives to Adobe Commerce for specific commercial and technical profiles. Understanding the trade-offs is key.
The replatform decision a steering committee should refuse to make
A replatform decision is a capital commitment, not a technical one. Without quantified business drivers, a steering committee risks approving an expensive project with ambiguous returns.
What a good rescue plan looks like when a site is already live
A rescue plan for a live site involves methodical diagnosis, immediate stabilisation, and strategic remediation, balancing quick fixes with long-term architectural health.
How to spot a commerce project that is about to drift
Learn to identify early indicators of a drifting commerce project, from scope creep to communication breakdowns, to prevent delays and budget issues.
Launch weekend: the runbook items most teams discover too late
Launch weekend runbooks frequently miss critical operational items that only become apparent during go-live. Prioritise these often-overlooked elements.
What makes an ecommerce project supportable after launch
For an ecommerce project to be supportable, it requires clear documentation, established patterns, and a robust support framework. Supportability should be a core design principle.
Adobe Commerce upgrade discipline: what to automate, what to refuse
Discipline in Adobe Commerce upgrades combines strategic automation with considered manual intervention. We outline what should be automated, what to scrutinise, and what to reject.
In conversation with a CFO who funded a rescue: what the board needed to hear
A CFO's view on funding a commerce engineering rescue: assessing viability, managing board expectations, and understanding the true cost of inaction.
Customer master data across CRM, ERP and commerce: the merge rules nobody writes down
Addressing customer master data management across CRM, ERP, and commerce platforms proactively, not reactively, is critical for B2B merchants.
The ecommerce features that sound good but rarely pay back
Certain ecommerce features, despite sounding good on paper, frequently fail to deliver expected returns, misdirecting investment and effort. We explore common examples.
Rescue debrief: the four signals that mean the platform is not the problem
Often, platform projects fail and the technology gets the blame. We outline four signals indicating the platform isn't the problem, but rather governance or strategy.
CLS on PDP: the layout shifts merchandisers keep introducing and how to stop them
Cumulative Layout Shift (CLS) on PDPs affects user experience and search rankings. Learn how merchandising choices trigger CLS and how to prevent it.
When the rescue is the supplier relationship, not the codebase
Addressing commercial issues within a supplier relationship is frequently the critical path to resolving systemic problems in a commerce operation, often before codebase intervention.
Ecommerce discovery: what should actually happen
Discovery is often misunderstood as a pre-sales phase. It is a critical project phase mapping business, technical, and strategic objectives.
The difference between a website rescue and a website rebuild
A website rescue aims to stabilise and improve an existing platform. A rebuild replaces it entirely. Defining the boundary dictates approach and outcome.
INP on Adobe Commerce: the four interventions that moved it below 200ms
Four critical interventions for improving INP on Adobe Commerce: focus on third-party script optimisation, main thread work, JavaScript execution, and server response time.
Rescue benchmark: the eight metrics we measure on day one and what good actually looks like
When a project is failing or performance is poor, we establish a baseline with eight key metrics on day one to inform rescue strategies.
Rescue benchmark: what the first thirty days actually cost
Understanding the true cost of an Adobe Commerce rescue involves more than just headline figures. We dissect the first 30 days' expenses, identifying key determinants.