What Makes Connecting a Legacy System Expensive When It Only Produces Files

The price of an automation project is not set by the logic in the middle. It is set by the way in and out of your systems. An ERP with a documented interface and a test environment is connected in days. The same business process costs several times as much when the system only hands over its data through a nightly file export.

You can check this before requesting any quote, without technical knowledge. A good starting point is a symptom that shows up in almost every such export: broken accented characters.

A five minute test you can run yourself

Ask for a current export from the system in question, open it in a plain text editor rather than in Excel, and look for a customer name with an accented character. If it reads Müller, you are fine. If it reads Müller or M?ller, you have a finding.

The pattern has a name, mojibake. One character turns into two wrong ones, the euro sign turns into a sequence of three. It looks cosmetic. It is a signal about how this system hands data to the outside world.

Why Müller turns into Müller

A computer stores numbers, not letters. The translation table between the two is called character encoding. UTF-8 is the current default, while older tables such as Windows-1252 live on, and there an accented character carries a different number.

As long as a system only writes and reads its own data, nobody notices. The trouble starts at the border between two systems. One writes using the old table, the other reads using the new one, and a single character becomes two wrong ones. The stored data is unchanged, only the interpretation is wrong.

On its own this is quickly fixed. You tell the automation which table the file was written in. The real question is what the finding says about everything else. A system whose export does not document its encoding usually does not document the rest either.

What else a file export costs you

With a proper interface, the automation asks for data and receives either a valid answer or an error. With files, all of that has to be rebuilt.

The automation has to detect whether the file is completely written, otherwise it reads half a file and processes half the orders. It has to prevent the same file being processed twice, otherwise you get duplicate postings. It has to notice when an export fails to appear, because a missing file produces silence rather than an error. It has to survive a change in column order that nobody announces after an update. And it has to decide what happens to rows that do not match the expected layout.

None of this is difficult. All of it is work, and it recurs in every project. If one quote says connection via interface and another says processing of export files, you are comparing two different amounts of effort.

The detour through Excel is the real risk

In many companies there is a person with a spreadsheet between the export and the next step. They open the file, add a column, sort it, save it again and drop it in the folder the automation reads from.

That is where most incidents start. Depending on the version, Excel writes back a different encoding, adds an invisible marker at the start of the file, turns an article number with a leading zero into a number without it, turns 03.11 into a date and a long number into scientific notation. The employee does nothing wrong. On screen the file looks correct.

For your buying decision the rule is simple. If a human opens and saves a file anywhere in the chain, that handling belongs in the process description. Often the cheapest solution is to remove that step entirely and move the manual addition into the automation.

Four questions for the vendor of your legacy system

They cost nothing but a phone call. Is there a documented interface, and what does enabling it cost. Is there a test system or at least a test client, because nobody may experiment on a production system. Is the export format documented, including encoding, separator and field meaning. And is there a contact who answers within a week.

Those answers move the price of an automation project far more than any decision about platform or language model. Without a test system every project takes longer. Without documentation every special case becomes manual research.

When replacing beats connecting

There is a point where connecting a legacy system costs more than working around it. You reach it when the vendor offers no interface at all, when the export has to be triggered by hand, when the system supplies no reliable key, or when support is being discontinued anyway.

The honest recommendation then is not to build an expensive bridge that wobbles with every update, but to first settle how long this system is meant to stay. An automation that has to last two years may be built differently from one meant to last ten.

Sophera Consulting therefore looks at how each system hands over its data before quoting, records format, exceptions and responsibilities in writing, and only then names a fixed price, with no subscription and with handover and documentation included. The entry point is the free Automation Check.

The recommendation

Before your first supplier conversation, write down on one page how every system involved gives up its data: interface or file, test access or none, documented format or not, human in the chain or not.

With that page you get comparable offers and a fixed price that holds. Without it you get a price for the normal case, and the effort for everything else arrives later as a change request.