Switching Shopware partners without downtime or technical surprises

You're unhappy with your current Shopware partner. Updates take too long, bugs pile up and there's no roadmap. Yet you stay, because switching feels riskier than staying. "Nobody else knows this code." It's probably the most common reason merchants stick with a partner they're no longer satisfied with.

That's a real fear, and it's not a silly one. Your live shop is your revenue. You don't just hand that over to someone who has never seen the codebase.

Every takeover at Kraftware starts with a free technical audit. Only once we know exactly where your Shopware project stands do we decide together how to move forward.

We've taken over several Shopware shops from other agencies. Almost every time we notice this causes a lot of stress and doubt for the merchant, because it often feels like a leap into the unknown. That's why I'd like to outline how the process works at Kraftware, and why we don't just take the keys and start typing.

Why switching feels so hard

Maybe you recognize yourself in this? The reasons to stay are rarely truly about content — they're practical and psychological.

Knowledge lock-in. One party, and sometimes even just one person within that company, knows the code, and nobody knows exactly how much work it takes to transfer that knowledge.

Fear of breaking things. As long as the shop is running, every change is a potential problem. A takeover feels like the biggest change of all.

Sunk costs. You've invested many years and large budgets in this project. Leaving the partner who built it feels like throwing away all that work, even though that's not the case and you simply continue on the same Shopware store.

Uncertainty about access. Are you not sure whether you actually own your domain, hosting, repository and licenses? And you don't dare ask while you're still working together, for fear of rocking the boat.

Signs it's time to move on

Not every minor inconvenience is a reason to switch. Sometimes a conversation is enough, and things can continue just fine with the same people. But a few things almost always come up with shops that eventually do make the switch:

• You only talk to an account manager, never directly to a developer or to the people actually working on your website. Every technical question goes through a translation layer, and a lot gets lost that way.
• Updates have become a project in themselves. Every Shopware update is expensive, nerve-wracking, or simply postponed.
• There are parts of your site that you're told not to touch. This blocks new features and updates, and is a source of stress for both you and the developers.
• Invoices are vague. Hours are billed but you don't see results.
• There's no roadmap, no plan for the next 6 months, nor for the long term. For a growing webshop, it's essential to create a solid plan together.

Any one of these is worth a conversation. If you're hitting multiple frustrations, it's a structural problem.

Important: this isn't about bad agencies. Sometimes things genuinely went wrong, and sometimes you've simply outgrown your partner (or your partner has outgrown you) or their way of working no longer fits where you are now. Both are valid reasons to look further.

Why we don't just take over the reins

This is where we differ from what you might expect. If you come to us with an existing shop, we don't start building features right away.

We never blindly take over an existing codebase. Otherwise we inherit the problems from the previous project, and you end up paying for that.

Projects coming from another agency always get a code review first. We want to have confidence in the codebase before we take on the responsibility of keeping it up to date. When we sign up for that responsibility, we need to know what we're saying yes to. It may be that we only accept a project under certain conditions, after a major cleanup round, or sometimes, unfortunately, have to decline adopting certain code altogether.

Step 1: the audit

The audit is always the first step of the takeover. Not an administrative formality, but the moment where unknown risk can be made known.

Our Shopware audit looks at, among other things:

• Code quality and architecture. How was this built, and does the structure hold up when something is added? Can we continue building on the existing website without too many issues?
• Update safety and core overrides. This is the most critical part. Every modification outside the official extension points increases risk with future updates.
• Plugin compatibility and dependencies. Which plugins are in use, are they still maintained, and what's blocking a version upgrade? Is everything custom? Are there many Store plugins in use?
• Performance bottlenecks. Why does a product page take three seconds? Why is the checkout slow? Is the problem in the code or in the infrastructure?
• Security. Are there known active vulnerabilities, or is the Shopware version seriously outdated?

You'll receive a prioritized report and a meeting where we walk through it together. Even if you then decide to stay where you are. An audit is useful as a second opinion, regardless of who does the work afterwards.

An audit is never wasted effort. It gives you an objective view of the technical state of your Shopware project, regardless of the next step. If you decide to have us carry out the takeover, we cover the cost of the audit entirely. If you choose to stay with your current partner or work with another agency, the audit costs €1,799. For an actual takeover, we absorb the cost of the technical audit. If you only want an independent technical analysis without further collaboration, that's also possible as a standalone audit.

Step 2: the ownership check

This is the most underestimated step in switching agencies, and one you can start on yourself today.

Go through this list and note who owns each item. Not who manages it, but who actually owns it.

• Domain name. Is the registration under your company, or under your (previous) agency's?
• Hosting. Whose account is the server running on, and who can cancel it tomorrow? Do you have full access to the server?
• Repository. Where is the code, and do you have access? Do you get the full git history, or just a zip of the latest version?
• Shopware licenses and plugin licenses. Under whose account were they purchased?
• Payment providers, shipping partners, ERP integrations. Are those accounts in your name?
• Data. Can you get a full database export and a media export?
• DNS, email, analytics, Search Console. All the ancillary software that sometimes gets overlooked in the rush.

If there are unknowns or gaps here, that doesn't necessarily mean there are problems. Often these services or products have grown organically: something was set up quickly at some point, and nobody corrected or properly handed it over afterwards. It's important to map these things out before you cancel. Negotiating access is much easier while the collaboration is still ongoing.

Step 3: cleanup before we build

The audit produces a list. Not everything on it needs to be fixed immediately, and we'll tell you that. But there are a few things we want in order before we truly get to work. You can't build on a bad foundation.

1. Remove core overrides and replace them with the official extension points. This is what makes a shop update-safe again.
2. Document or clean up dirty hacks. Sometimes a "hack" was the right solution under time pressure. Then it can stay, but it gets documented with the reason why. Ideally, we look for a sustainable solution.
3. Update to the latest Shopware version. Falling behind only gets more expensive the longer you wait. We like to update at least to the latest version within your current major.
4. Document everything. What runs where, which integrations exist, what was intentionally done differently. So the next person (even if that's not us) doesn't have to guess all over again.

This phase is work, and therefore a cost. We don't hide that. What you get in return is a shop where the next update is no longer a circus. On top of that, your shop is also ready to (optionally) move onto our Evergreen plan. The first update to the latest version is explicitly billed outside the subscription, at our normal rate, precisely because the size of that catch-up effort varies greatly per project.

This phase is not optional work: preparing an existing Shopware shop for the future takes time and attention. We'd rather not promise that everything will be "magically" resolved.

What you get in return is a stable foundation you can build on again. Updates are no longer a risky catch-up exercise, but a predictable part of managing your webshop. The size of this cleanup round varies significantly per project.

Afterwards, you can optionally choose to bring your shop under Evergreen, so that future updates and technical maintenance are structurally managed.

Meanwhile, your shop keeps running

This is usually the question that matters most, so let's be explicit: there is no moment where we pull the plug and hope it comes back on at the other end.

The audit doesn't touch your live shop. The cleanup work happens in stages, with testing and in a staging environment. We only go live once we're ready. The truly nerve-wracking steps (a major version jump or a hosting migration) are planned together, at a time that suits you, with an appropriate plan B or fallback scenario that we agree on before we begin.

Time is money, but downtime costs even more. So we always try to minimize that as much as possible.

And only then: building further

After the cleanup, we continue building on a codebase we trust, with direct contact between you and the developer working on your shop. No account manager, PM, PO, or AI chatbot as a middleman.

If you don't want updates to keep coming back as separate projects, then Evergreen is the next step: security updates within the week, minor and patch updates every quarter, major updates planned together, for a fixed monthly fee. That's not an obligation, but it is what this entire process works towards: switching agencies shouldn't be something you have to do again in three years.

Audit, ownership check, cleanup, then build. That order is the whole difference between a switch that feels like a gamble and a switch that feels like a stable handover that we both step into with confidence.

And the beauty of the first step: it commits you to nothing. An audit tells you what's really underneath your shop, even if your conclusion is to stay where you are, or to go with a different party.

So, the key questions: do you know today who owns your domain, your hosting, and your repository? If you had to hesitate on any of those three, that's the first thing I'd sort out, regardless of who you end up working with.

Not sure if your Shopware project is ready for a handover? Start with a technical audit. You'll get an objective picture of the state of your shop, with no obligation to continue with us afterwards.