Introduction
Taking over an established Magento store from another agency can be an interesting experience.
Sometimes, you inherit a well-built platform that has been carefully maintained, documented and developed over a number of years. There may be areas you would approach differently, but the foundations are solid.
However at other times, you look under the bonnet and realise you have a rescue mission on your hands.
At Fluid Commerce, we regularly inherit B2B and D2C Magento stores that aren’t performing as well as they should. That can mean poor site speed, unreliable integrations, unexplained checkout problems, security concerns, difficulty deploying new features or a platform that has simply become increasingly expensive and difficult to maintain.
Often, the problems aren’t immediately obvious to the merchant. The storefront may look perfectly respectable. Customers can browse products, add them to their baskets and place orders. But underneath that frontend can be years of technical debt, shortcuts, patches and custom development that have gradually made the platform less stable.
That’s why taking over an existing Magento B2B or D2C store isn’t simply a matter of getting the logins from the previous agency and starting work on the next development ticket. The first priority for us is to understand what we’ve inherited and what the immediate Magento support requirements are.
The symptoms aren't always the problem
When a merchant approaches Fluid Commerce because they are unhappy with their existing Magento store, they usually already have a list of problems.
The merchant might list the following problems:
- The website is slow
- Orders occasionally go wrong
- Stock isn’t always accurate
- Deployments are painful.
- The checkout has strange edge cases.
- Magento upgrades have become increasingly difficult.
These are important symptoms, but they’re rarely the whole story. Our job is to work backwards and understand why those things are happening so that we can recommend strategies to fix them and make the site stable.
A recent example is our work with D2C food gifting company Cartwright & Butler. Cartwright & Butler is a fantastic brand with much ecommerce potential but there were issues with its Magento site that we needed to address before we could push ahead with the next phase of the project. These are issues that we also commonly see on other Magento sites we inherit and included:
- Poor integration with the ERP
- Code that didn’t have fallback scenarios causing problems
- Magento best practices not followed
- Pratices that prevent security patches and upgrades from being applied cleanly
Understanding the architecture
One of the first things we want to understand when inheriting a Magento platform is how everything fits together.
A modern ecommerce operation doesn’t consist of a website operating in isolation. Magento is often connected to an ERP, warehouse systems, payment services, product information systems, marketing platforms, and a collection of third-party services, making Magento integrations experience and knowledge vital.
ERP integrations are a particularly good example as they can appear to work perfectly well when everything happens exactly as expected. Magento requests some information, the ERP responds correctly and the process completes.
However at Fluid Commerce, we’ve inherited sites where ERP integrations had insufficient fallback behaviour when something went wrong, and the consequences can spread across the business.
Product information may stop updating. Pricing can become inaccurate. Stock availability can be wrong. In the other direction, order information may not export correctly from Magento into the ERP, potentially resulting in incorrect delivery methods or costs. Configurable products can introduce additional complications if the information being passed between systems isn’t handled correctly.
These aren’t cosmetic website bugs. They affect operations, fulfilment and ultimately the customer experience.
An integration therefore shouldn’t only answer the question, “What should happen when this works?” It also needs to answer, “What happens when it doesn’t?” and taking that approach helps us to prevent the problems that can occur.
Good ecommerce development expects the unexpected
Fallback behaviour isn’t limited to integrations; it’s something we look for throughout the Magento codebase.
Developers naturally build functionality around expected user journeys. The customer selects option A, enters information B and proceeds to C.
But customers frequently do things that nobody expects them to, so when building an ecommerce store we have to be well-prepared for that
One issue we identified with Cartwright & Butler illustrates that point well. For certain hampers, customers are expected to select a delivery date when adding the product to their basket. The standard journey assumed that this selection would be made.
However, due to a coding error, it was possible for a customer to reach checkout without selecting the delivery date. Because the code didn’t adequately handle that alternative scenario, the customer could bypass part of the intended process and avoid paying the associated delivery charge.
Individually, a bug like that might look relatively small. But it demonstrates a much larger principle. Code shouldn’t only work for the perfect journey. It needs to be able to handle imperfect journeys, missing information, failed responses and unexpected behaviour.
Whenever we take over an existing Magento store, we’re interested in the paths that aren’t obvious. What happens if information is missing? What happens if an API is unavailable? What happens if a third-party service responds slowly?
It’s when those questions are asked that inherited Magento platforms can start to unravel.
Magento best practice exists for a reason
There are usually several ways to achieve something in Magento, however, that doesn’t mean they’re all good ways.
Adobe Commerce and Magento Open Source have established development patterns for accessing data, extending functionality and interacting with the underlying platform.
Ignoring those patterns can make development appear quicker initially, but the bill tends to arrive later.
One of the more concerning practices we’ve encountered on inherited stores is custom functionality making direct SQL queries against the Magento database.
It might solve an immediate development problem, but it bypasses the abstractions Magento provides for interacting with its data. The implementation becomes more tightly coupled to the database structure, future Magento changes can break functionality unexpectedly, and testing and maintenance become harder. Poorly implemented queries can also have significant performance implications and introduce security concerns.
When conducting a technical review, we’re therefore not simply asking whether the code works today.
We’re asking whether it has been developed in a way that allows the platform to remain secure, maintainable and upgradeable tomorrow.
Security can't be an afterthought
Another area we examine closely at Fluid Commerce is how sensitive credentials are being managed.
API keys, passwords and other security credentials should never be treated like ordinary configuration values. Yet we’ve encountered credentials hard coded into custom Magento modules and, even more concerningly, committed into Git repositories.
Once a credential has entered version control, removing it from the current version of a file doesn’t necessarily remove the exposure. It may remain within the repository history.
That can turn what appears to be a simple code tidy-up into a security issue requiring credentials to be rotated and the wider exposure assessed.
These problems aren’t always caused by dramatic acts of negligence. Often, they’re the result of shortcuts taken during development that were never revisited. That’s exactly why they can survive unnoticed for years.
A Magento rescue mission needs to consider security alongside performance and functionality rather than treating it as something to worry about later.
Core hacks are a warning sign
There are certain discoveries that immediately tell you a lot about the history of a Magento build. Core hacks are one of them.
Magento is specifically designed to be extended without directly changing its core functionality. There are established mechanisms for customising and overriding behaviour while keeping the underlying platform intact.
Despite that, we still inherit stores where developers have copied entire Magento modules into app/code/Magento and modified them directly.
It can work for a while, but the problem becomes apparent when Magento needs to be upgraded or a security patch needs to be applied.
When entire modules have been copied and changed, you effectively have your own version of Magento’s core code sitting inside the application. Every upgrade becomes more complicated because somebody has to understand which parts have been changed, why they were changed and whether those changes are still required.
Security patches become more difficult to apply cleanly and the technical debt compounds. Eventually, an apparently straightforward Magento upgrade can become a substantial development project.
Removing these kinds of core modifications and rebuilding the required functionality properly can therefore be an important part of stabilising an inherited store.
The danger of the invisible workaround
Accumulated technical problems are also frequently present in the Magento sites we inherit.
A deadline is approaching, so a developer implements a workaround. A third-party integration behaves unexpectedly, so another piece of code is added. A Magento upgrade causes an issue, so something gets overridden rather than properly refactored.
Each decision can seem understandable in isolation. Five years later, nobody remembers why half of it exists and the code is an unorganised mess.
This is why one of the most dangerous phrases when inheriting an ecommerce platform is: “Don’t touch that because we’re not sure what it does.”
A mature ecommerce platform will naturally contain custom development. That’s not inherently a problem. The question is whether that customisation is intentional, maintainable and understood.
Part of a rescue project is separating valuable business logic from technical baggage.
We don’t want to remove custom functionality simply because it’s custom. Bespoke functionality might represent years of knowledge about how that merchant actually operates.
Instead, we need to understand its purpose and determine whether the implementation is still appropriate. Sometimes the answer is to refactor it. Sometimes it’s to replace it with native Magento functionality or a better extension. Sometimes it’s to leave it alone.
The important thing is that it becomes a conscious technical decision rather than another unknown buried in the codebase.
Fixing everything at once is rarely the answer
Once you’ve identified a long list of issues, there’s an understandable temptation to fix everything immediately.
That’s rarely the most sensible approach on a live ecommerce store. A rescue needs prioritisation to ensure its success and longevity.
Security vulnerabilities and issues that could prevent customers from ordering naturally demand urgent attention. Problems affecting order accuracy, stock, pricing or integrations can have a direct commercial and operational impact and need to be treated accordingly.
Other technical debt may be significant without being immediately dangerous.
The objective is to move the platform from reactive firefighting towards controlled improvement. That means understanding dependencies before making changes, introducing appropriate testing and gradually replacing fragile areas without unnecessarily disrupting trading.
For merchants, this can be one of the biggest changes after moving away from an agency relationship that hasn’t worked.
Instead of every development conversation beginning with the latest problem, you can start having conversations about what the platform should do next.
Performance problems often have deeper causes
Poor Magento performance is another common reason we’re brought into an existing project.
Magento performance can be affected by custom modules, database queries, third-party extensions, caching configuration, frontend implementation, integrations and infrastructure.
If poor development practices are causing excessive database activity, it can be tempting to believe that throwing additional infrastructure at the problem might temporarily disguise it. However this is rarely a solution. This is why performance work needs to start with investigation rather than assumption.
The same principle applies across the rescue process. We want to fix causes rather than continually treating symptoms.
Getting Magento back to an upgradeable state
For me, one of the clearest signs that a rescue has been successful is when the platform becomes predictable again.
Deployments shouldn’t feel dangerous. Security patches shouldn’t trigger weeks of uncertainty. A Magento upgrade shouldn’t require forensic analysis to understand which pieces of core code somebody changed three years ago.
Integrations should fail gracefully rather than bringing processes to a halt, and developers should be able to understand the code they’re working with without relying on undocumented knowledge held by one person.
This doesn’t mean every line of technical debt has disappeared. No established ecommerce platform is perfect, and trying to make it perfect can become an expensive distraction in itself. The aim should be to create a healthy technical foundation.
For Magento merchants, being upgradeable is an important part of that. Security patches and platform releases will continue to arrive. A store that becomes progressively harder to update isn’t standing still; it’s accumulating future risk.
Restoring a clean upgrade path can therefore be just as valuable as delivering a new customer-facing feature, even if shoppers never directly see the work involved.
What merchants should expect from a Magento rescue
Changing ecommerce agencies can feel daunting, particularly when a platform contains years of custom development.
But the process is not as difficult as a company might think when transferring a site to an experienced and knowledgeable Magento agency that will be able to fix the imperfect codebase without completely starting the site over.
In many situations, the underlying Magento platform is perfectly capable of supporting the business. The challenge is identifying what has gone wrong around it and systematically putting those things right.
That requires technical investigation, but it also requires judgement. You need to know which problems are urgent, which can wait and which pieces of custom development are genuinely valuable to the business.
The specific issues differ from merchant to merchant, but the patterns are remarkably familiar: fragile integrations, missing fallback logic, development that doesn’t follow Magento best practice, security concerns and customisations that make upgrades far more difficult than they need to be.
The good news is that these problems are fixable, and a badly managed Magento store doesn’t necessarily need replacing. Sometimes it needs an experienced team to understand what has happened, stabilise the foundations and give the platform a clear technical direction again.
It’s not about arriving with a long list of everything the previous agency did wrong. It’s about understanding what the merchant has today, reducing the risks that have accumulated over time and creating a platform that the business can confidently build on tomorrow.
Concerned about the state of your Magento store?
If your Magento or Adobe Commerce platform is slow, difficult to upgrade, suffering from recurring problems or simply isn’t delivering what you expect, Fluid Commerce can help you understand what’s happening beneath the surface.
Get in touch with Fluid Commerce to talk to our Magento team about your platform.
