We recently took over a webshop generating more than 10 million euros in annual revenue.
The webshop worked. Customers were buying. Orders were coming in smoothly.
At first glance, there was no major problem.
But when we started taking over the system, the first questions weren't about new features or development.
They were much simpler:
- Where is the current source code located?
- Who has access to the repository?
- Who manages the domains and DNS records?
- Where is production, and where are the test systems?
- What does the backup strategy look like?
- How is a restore performed?
- Who responds if the webshop stops working?
- Is there a contracted 24/7 SLA?
For a webshop generating several million euros a year, these aren't just technical questions.
They are questions of business continuity.
And they very quickly lead to another, perhaps the most important, question:
Could you change the partner maintaining your webshop tomorrow?
What does vendor lock-in actually mean?
Working with the same ecommerce partner for five or ten years isn't a problem in itself.
In fact, a long-term partnership can be a big advantage because the partner knows the business, the system, and the processes well.
The problem arises when a company no longer has a real ability to choose.
If changing partners means it's hard to get to the source code, that only the existing vendor knows how the system works, that it's unclear what's located where, or that another partner would practically have to rebuild a large part of the system – the company is in vendor lock-in.
In other words, the problem isn't that you don't want to change partners.
The problem is if you can't change them without major cost and risk.
Vendor lock-in usually doesn't happen overnight
There is rarely a moment when someone makes the decision: "Let's build a system that will be impossible to hand over to another partner."
Lock-in more often happens gradually.
A webshop develops over years.
New features are added. An ERP is connected. Logistics is added. A new market opens. A new integration is built. Somewhere a temporary technical solution is made that, after a few years, is no longer temporary.
As long as everything works, there's little reason to question such things.
The problem only becomes visible when a bigger change is needed.
In the system we took over, for example, part of the custom development had been built directly into the core parts of the nopCommerce platform.
That could work for years.
But the consequence was that every serious platform upgrade became extremely demanding.
And a platform needs to be upgraded for security, compatibility, performance, and new features.
If every upgrade becomes a separate, large development project, technical debt grows – and with it grows the dependency on the people who know why the system was built that particular way.
Source code is only part of the problem
When vendor lock-in is discussed, the first thing that often comes to mind is ownership of the source code.
That's important, but it's not enough.
You can have the source code and still have a system that's extremely difficult for another partner to take over.
You also need to know:
- how the application is deployed,
- where individual systems are located,
- which applications communicate with each other,
- who has administrative access,
- how the integrations work,
- how backup and restore are done,
- which components are part of production,
- what will happen if a particular server or service is shut down.
In our project, one of the more interesting discoveries was that servers considered to be test servers actually hosted applications that were part of the production process.
Such situations usually don't happen because of one big wrong decision.
They happen gradually.
Something gets installed temporarily. The temporary solution stays. After a few years, no one is fully sure what can be shut down and what depends on what.
As long as the system works, this may not be visible.
When someone else needs to take it over, it becomes a big problem.
The real cost of vendor lock-in appears when you want to change something
Vendor lock-in doesn't necessarily create a visible problem in day-to-day business.
A webshop can run for years.
The cost most often appears when a company wants to do something new.
For example:
You want to open a new market.
In our case, there were two separate webshops for two markets, with two separate codebases.
That means two applications to maintain, duplicate implementation of certain changes, more complex testing and deployment, and a greater risk that functionality between the markets starts to diverge.
The platform already supported the multistore concept, so we consolidated the two separate systems into a single application with two stores.
You want to change how product data is managed.
The webshop was directly connected to the ERP, which didn't serve only as an ERP.
It was also a source of product data, a kind of PIM, and part of the logistics process.
Such an architecture can work for a long time.
The problem arises when you want a new sales channel, a marketplace, a new market, a new logistics system, a real PIM, or one day want to change the ERP.
Then something that looked like a practical solution for years can become a serious constraint.
You want to change development partners.
That's when it first really matters how well the system is documented, who controls the infrastructure, how closely development followed the platform's rules, and whether a new team can understand the system without months of "analysis and discovery."
Vendor lock-in is therefore not just an IT issue.
It directly affects the cost and speed of future business changes.
Getting out of vendor lock-in doesn't mean you have to build a new webshop
When a large amount of technical debt is discovered, one of the first ideas is often:
"It's best to build everything from scratch."
We don't automatically agree with that approach.
Especially when the existing webshop generates more than 10 million euros in annual revenue.
Building a new ecommerce system or switching to another platform means a big project, significant cost, and new business risk.
That's why in this case we chose gradual modernization.
When a specific business enhancement was being made, we simultaneously fixed part of the existing architecture.
When we changed functionality that had been implemented in the core, we extracted it into a plugin.
When changes were needed for both markets, we consolidated the two webshops into a multistore architecture.
When we worked on infrastructure, we separated the production and test systems and removed old, unnecessary components.
Technical debt wasn't resolved through one big, expensive project.
It was resolved step by step, together with the development of features the business needed anyway.
What does the system look like today?
After the takeover, the situation is significantly different:
- ownership and location of the source code are clear,
- the development process is controlled,
- customizations have been extracted into plugins,
- the platform has been re-prepared for future upgrades,
- two separate webshops have been consolidated into one multistore system,
- production and test infrastructure are separated,
- responsibilities for key parts of the system are more transparent,
- the remaining architectural dependencies that need to be gradually removed have been identified.
The work isn't finished yet.
One of the next steps is gradually separating the responsibilities of PIM, logistics, and ERP.
But there's a big difference.
The company now knows what it has, how the system works, and in what order it can modernize it without stopping the business.
A simple test: are you in vendor lock-in?
Ask yourself one question:
If we decided to change ecommerce partners tomorrow, could we hand over the system without any problems?
Can you give them access to the current source code and repository?
Do you know who controls the domains, DNS, and infrastructure?
Is there documentation for the key integrations?
Do you know how the system is deployed?
Is there a documented backup and restore procedure?
Do you know exactly which systems make up the production ecommerce environment?
Can another team upgrade the platform without first spending months discovering how the system was built?
If your answer to several of these questions is "I'm not sure," that doesn't necessarily mean you have a bad webshop.
But it does mean you might not have as much control over it as you think.
A good ecommerce partner should be replaceable
It might sound paradoxical, but one of the signs of a quality technology partnership is precisely the ability to change partners.
Source code, infrastructure, documentation, and key access should be under the company's control.
Development should follow the platform's architecture.
Integrations should have clear responsibilities.
And knowledge of the system shouldn't exist solely in the heads of a few people at one vendor.
The goal isn't to have a technically perfect webshop.
The goal is to have an ecommerce platform the company is in control of, one that lets it grow over the next five or ten years.
Regardless of who develops and maintains it at that point.
Do you have a webshop that's been running for years, but you're not entirely sure who controls the source code, infrastructure, backups, integrations, or upgrade process?
That doesn't necessarily mean you need a new webshop.
You might first need to determine how much real control you actually have over the existing system, remove the biggest risks, and create a realistic plan for its gradual modernization.
We took over a webshop with more than €10 million in annual revenue. The first problem wasn't the code.
A webshop can generate more than 10 million euros in annual revenue, process orders smoothly, and from the outside look like a fully functional ecommerce system.
All while its owner doesn't know where the source code is located.
Doesn't know who manages the DNS.
Doesn't know what the backup plan is.
And isn't sure whether there's a contracted 24/7 SLA or only support during business hours.
This is exactly the situation we encountered when taking over an existing ecommerce system built on the nopCommerce platform.
The webshop worked. Customers were buying. Revenue was being generated.
But beneath the surface there was a lot of technical and operational debt that was becoming an increasingly large business risk over time.
The problem wasn't just the technology
The first step in the takeover wasn't developing new features.
It was answering basic questions:
- Where is the current source code located?
- Who has access to the repository?
- Who manages the domains and DNS records?
- Where is production, and where are the test systems?
- What does the backup strategy look like?
- How is a restore performed?
- Who responds in the event of an incident?
- Is there a 24/7 SLA?
- Which systems depend on each other?
For a system generating several million euros a year, these aren't technical questions.
They are questions of business continuity.
If the webshop stops working on a Saturday evening, it's not enough to know the name of the development agency. You need to know in advance who responds, within what timeframe, with what access, and according to what procedure.
Years of development without clear rules
After we gained an overview of the infrastructure and source code, a second problem emerged.
A large part of the previous enhancements hadn't been built in line with the recommended way of extending the nopCommerce platform.
Custom changes had been made directly in the core parts of the system.
The result?
Every serious platform upgrade became extremely difficult.
For ecommerce platforms, this is particularly problematic. A platform must be able to be upgraded for security, compatibility, performance, and new features.
If every upgrade is practically a new development project, technical debt just keeps growing.
That's why we gradually extracted the existing customizations from the core and moved them into plugins.
This wasn't just "cleaning up the code."
We enabled the platform to be developed and upgraded again in a controlled way.
Two countries, two webshops, two codebases
The customer operates in two markets.
It would be logical to expect a single ecommerce system managing two stores.
But the situation we found was different.
There were two separate webshops and two separate codebases.
That means:
- two applications to maintain,
- duplicate implementation of individual changes,
- a greater risk that functionality between the markets starts to diverge,
- more complex deployment,
- more complex testing,
- higher cost of future development.
nopCommerce already supports the multistore concept.
That's why we consolidated the two separate systems into a single application with two stores.
One codebase.
One place for development.
Simpler maintenance.
Lower operational risk.
And a significantly better foundation for future expansion into additional markets.
Production on test servers
One of the more interesting discoveries during the takeover was that servers considered to be test servers also hosted applications that were actually part of the production process.
Such situations usually don't happen because of one big wrong decision.
They happen gradually.
Something gets installed temporarily.
Then it becomes permanent.
After a few years, no one is fully sure what can be shut down, what's being used, and what depends on what.
That's why part of the takeover was also an infrastructure cleanup.
Production, test, and development systems were clearly separated again, the services and their responsibilities were documented, and what actually constitutes the production ecommerce system was defined.
The ERP was an ERP, a PIM, and a logistics platform
The next challenge didn't need to be solved right away, but it did need to be clearly identified.
The webshop was directly connected to the ERP system.
The ERP wasn't used just for finance and business processes.
It was also used as:
- a source of product data,
- a kind of PIM,
- part of the logistics process,
- the system used to manage the information needed for shipping packages.
In other words, the architecture was practically not decoupled.
A change in one system could have consequences for several other processes.
Such an architecture can work for years.
The problem arises when the business wants to introduce changes faster.
A new sales channel.
A marketplace.
A third market.
A new logistics partner.
A new PIM.
A change of ERP.
Then tightly coupled integrations very quickly become a limitation.
That's why the next phase of modernization includes gradually separating responsibilities:
The ERP should do the job of an ERP.
Product data should be managed by a system specialized for product data.
The logistics process should have a clearly defined integration interface.
And the ecommerce platform must not depend on the implementation details of every individual system behind it.
Most importantly: we didn't do a big rewrite
With systems like this, an idea often comes up:
"It's best to build everything from scratch."
We don't automatically agree with that approach.
Especially when the existing webshop generates more than 10 million euros in annual revenue.
A big rewrite means a big project, big risk, and very often a very big cost.
Instead, we chose gradual modernization.
When a specific business enhancement was being made, we simultaneously fixed part of the existing architecture.
When functionality that had been implemented in the core was being changed, we moved it into a plugin.
When changes related to both markets were needed, we consolidated the two webshops into a multistore architecture.
When we worked on infrastructure, we removed old, unnecessary production components from the test servers.
In other words, technical debt wasn't resolved through one big, expensive project.
It was resolved methodically, step by step, together with the development of business-critical features.
Because of this, the customer wasn't exposed to extreme modernization costs or a big "big bang" project.
What does the system look like today
After the takeover:
- ownership and location of the source code are clear,
- the development process is controlled,
- customizations have been extracted into plugins,
- the platform has been re-prepared for future upgrades,
- two separate webshops have been consolidated into one multistore system,
- production and test infrastructure are separated,
- responsibilities for key parts of the system have become more transparent,
- the remaining architectural dependencies that need to be gradually removed have been identified.
The work isn't finished yet.
The next big step is decoupling PIM, logistics, and ERP.
But the difference is that today there's a clear roadmap for how to do that without stopping the business.
A webshop doesn't need to be replaced just because it has technical debt
This project showed something we often see with existing ecommerce systems.
The problem isn't necessarily the platform.
The problem is the way the system was developed and maintained over the years.
nopCommerce can be a solid foundation for a serious ecommerce system.
But only if:
- there is control over the source code,
- custom development follows the platform's architecture,
- there is a clear infrastructure,
- responsibilities are defined,
- the system can be regularly upgraded,
- integrations aren't unnecessarily tightly coupled.
That's why taking over an existing webshop doesn't automatically mean replacing it for us.
First we determine what's worth keeping.
Then we remove the biggest risks.
And only after that do we gradually modernize the architecture where there's a business justification for it.
Because the goal isn't to have a technically perfect webshop.
The goal is to have an ecommerce platform the company is in control of, one that lets it grow over the next five or ten years — without falling back into vendor lock-in and without having to rebuild everything from scratch every few years.
Do you have a webshop that's been running for years, but you're not entirely sure who controls the source code, infrastructure, backups, integrations, or upgrade process?
That doesn't necessarily mean you need a new webshop.
You might first need someone who can take over the existing system, stabilize it, and create a plan for its gradual modernization.
For many companies, an ecommerce platform starts out as a project: build an online store, launch it, and maintain it when something needs fixing. But once ecommerce becomes an important sales channel, that model is no longer enough.
Platforms need hosting, monitoring, releases, security updates, integrations, continuous development, and someone who takes responsibility when something goes wrong.
That's the idea behind Managed Ecommerce.
More than maintenance
Traditional maintenance is often reactive: something breaks, a ticket is opened, someone fixes it. Managed Ecommerce is a broader approach.
Xiphias takes on continuous responsibility for the operation and continuous development of the ecommerce platform.
Depending on the customer's setup, this can include:
- hosting and infrastructure
- backups and monitoring
- DevOps and CI/CD
- deployment and release management
- platform and security updates
- incident management and SLA
- operational support
- continuous development
- technical roadmap and periodic ecommerce audits
Instead of coordinating several vendors, the customer has a single technology partner responsible for the operation and ongoing development of the ecommerce platform.
Development capacity is already included
An ecommerce platform is never really finished. Business processes change, new integrations are needed, customers expect new features, and small improvements keep coming up.
That's why the monthly Managed Ecommerce fee includes a predefined number of development hours. These hours can be used for bug fixes, minor features, optimizations, and continuous improvements.
If they aren't fully used in a given month, the remaining hours can be carried over to the next month.
This gives customers predictable monthly costs while keeping the flexibility to use development capacity when it's actually needed.
Switching shouldn't mean starting from zero
Companies often stick with their existing ecommerce platform or vendor simply because switching seems too expensive. Even when there are good reasons to change — outdated technology, slow development, vendor dependency, or limited flexibility — yet another large initial ecommerce project is hard to justify.
Our approach is different.
For customers entering a multi-year Managed Ecommerce partnership, Xiphias can significantly reduce the initial cost of migration, modernization, or rebuilding. We can do this because we look at the economics of the entire long-term relationship, not just the initial implementation project.
The goal is to lower the barrier to changing an ecommerce setup that no longer supports the business.
A long-term partnership without technology lock-in
A long-term business relationship shouldn't mean permanent technological dependency. Customers should retain control over their ecommerce platform.
The source code and repository remain under the customer's control, and wherever appropriate we use established technologies that other implementation partners can also maintain.
The principle is simple: we want customers to stay because the partnership creates value — not because changing partners is technically impossible.
Start with a switch assessment for another ecommerce system
Changing ecommerce partners shouldn't automatically mean replacing everything. The first step is understanding the current setup.
An Ecommerce Switch Assessment can review:
- the existing platform
- ownership of the source code and repository
- vendor dependencies
- hosting and infrastructure
- integrations
- operational risks
- current pain points
- migration complexity
Sometimes the conclusion may be that switching currently doesn't make business sense. If it does, the assessment provides the foundation for defining the migration approach and the Managed Ecommerce model.
A platform that can grow with the business
Managed Ecommerce is also designed as a foundation for future development. Once the core ecommerce platform is stable, additional capabilities can be introduced when they create business value.
For example:
PIM and product data
Product information can be separated from the ERP and the ecommerce system using Pimcore, creating a central source for descriptions, attributes, images, languages, and channels.
Product content automation
Large catalogs can benefit from automated product descriptions, enrichment, categorization, and translation.
B2B ecommerce
Manual orders received by email or phone can gradually shift to digital self-service for customers.
International expansion
The platform can be prepared for additional languages, markets, and online stores.
Management reporting
BladeFX can provide ecommerce KPIs, operational reports, and management dashboards without needing a large BI project from day one.
These capabilities can be added gradually instead of trying to solve everything in one big transformation project.
Key takeaways
Managed Ecommerce isn't simply a maintenance contract.
It's a long-term operating model for ecommerce that combines:
- Infrastructure, DevOps, and operations
- SLA, monitoring, and operational responsibility
- Monthly development capacity with carryover of unused hours
- Continuous improvement and a technical roadmap
- Lower initial switching costs for long-term partnerships
- Customer ownership of the source code and repository
- A foundation for PIM, automation, B2B, reporting, and international growth
For companies that have outgrown their current online store or ecommerce vendor, the question doesn't have to be:
"How much will yet another new online store cost?"
A better question might be:
"What does it take to move to an ecommerce model that can be continuously run, improved, and scaled?"