Knowledge Area 2 · Before you decide
Before you decide · Integration

Letting existing systems live on.

DATEV, Lexware, the old ERP, the Outlook calendar, the Excel sheet that has worked for ten years - how new software brings all of that in, instead of destroying it. Six points.

What this is about

Almost every SME has a grown-up jumble of tools. The fear is usually: "If we build new, we have to throw everything away." That isn't true.

Modern building almost always means: alongside, not instead. A new application talks to the old systems, fetches what it needs, gives back what it delivers. Whoever masters that can modernise step by step, without touching accounting, payroll or customer records.

One

Nobody enjoys replacing everything.

If a provider tells you that you have to replace your DATEV, throw away your Excel lists and forget your Lexware - then they've either not understood your business, or they want to sell you exactly that. Neither is a good start.

Existing systems often carry decades of experience. They aren't pretty, but they're reliable, tested, documented, and your people know them well. What you need isn't the replacement, but the bridge - a new layer on top that creates visibility, without destroying the foundation.

Two

What an interface really is - in plain language.

An interface is nothing more than an agreed language in which two programs talk to each other. Program A calls program B and says: "Give me the invoice with the number 4711." Program B replies: "Here are the date, amount, customer, items." Done.

In the jargon this is called an API - Application Programming Interface. But the technical term isn't what matters. What matters is the idea: you don't have to retype, copy, export, import data. It flows. Where an interface exists, two programs are as good as one. Where none exists, an SME almost always has an employee who transfers it manually all day - that's the spot where building a bridge almost always pays off.

Three

The three most common existing systems - and what we do with them.

DATEV. Cumbersome, but indispensable for your accounting. We let DATEV do what DATEV does well - receipt capture, payroll, annual accounts. We build a separate layer for the spots DATEV doesn't do well - quote management, customer care, project overview. Data flows at month-end, not in real time. That's perfectly enough.

Lexware. For many smaller businesses the heart of it. Lexware has a well-known interface through which we can sync invoices, customers and items. A new enquiry in your system automatically becomes a Lexware record - without anyone retyping anything.

Old ERP or industry solution. Here it gets harder. Some old systems have no open interface. Then there are two ways: reading from the database in the background - or a pragmatic solution via regular exports. Both work, neither is elegant, both do the job.

Four

Excel isn't the problem.

Very many consultants say: "First, get rid of Excel." We don't. Excel is a surprisingly good tool. It's fast, everyone can use it, and for many small tasks it's better than any built software.

The problem only arises when Excel sheets circulate among several people, contradict each other, spawn versions and nobody knows any more which one is current. Then Excel becomes the brake. Our solution: Excel stays where it's good - model calculations, one-off analyses, quick overviews. What has to be accessible to several people in real time moves into a proper application. Both side by side, both connected.

Five

When an existing system becomes the brake - and when it doesn't.

There are two exceptions to the rule "let the existing system live on". You should know both.

Exception one: the system is no longer maintained. The manufacturer no longer exists, the updates no longer come, the security holes aren't being closed. Then staying is more dangerous than switching. Here a plan is needed - with time, with a transition phase, with protection.

Exception two: the existing system forces your people into double work that can't be fixed. If the old program is so closed that no bridge can be built, and at the same time four employees enter the same data twice every day - then at some point the maths is clear: replacing costs money once, staying costs time every month.

Six

How we actually go about it.

Before every new project we look at your existing landscape. We map it out - which system holds which data, what talks to what, where the gaps are, where double work arises. We call that a system map and it's usually the first real aha moment.

Only after that do we decide together: what stays? What gets added? What gets replaced? Most answers are stays and gets added. A handful of bridges, one central new interface, not much more. That's usually cheaper, faster and safer than the grand sweep.

Why big-sweep projects fail so often

The classic problem is called big-bang migration: an old system is run in parallel with the new one for months, and at some point there's a cut-over date on which everyone is supposed to switch. Studies from the ERP field (Standish Group Chaos Reports) have shown for decades: such projects fail in more than half of cases or end up far more expensive than planned.

The alternative is called the strangler pattern - a term from software architecture. Like a strangler fig around a tree trunk, new functionality slowly grows around the old system. Piece by piece, the old is used less, until at some point it's superfluous all on its own. Lower risk, slower in appearance, faster in result.

What these six points share

Modernisation doesn't mean redoing everything. It means putting what works into a new orbit.

If at the first meeting you get a proposal that was made without looking at your systems, you should be careful. Real integration work begins with listening and mapping - not with selling.

If you want to know how your landscape can be ordered

A short email with your three most important systems is enough. We'll tell you where bridges can be built and where they can't.

What our problem analysis before each build looks like is on Before we build, we figure out what's broken. What software realistically costs is on What software really costs. Why SME projects most often fail is on Where SME projects fail.

More in Area 2
Before you decide
← Before
Where to start with AI?
Next →
Funding for digitalisation
Back to the knowledge base