Enterprise Integration

Enterprise Integration

When your systems don't talk to each other, your team fills the gaps by hand. We connect your ERP, CRM and warehouse systems so numbers stop being re-keyed, starting with the one connection that pays back first.

The systems are not the problem. The gaps between them are.

What enterprise integration actually means

An empty boardroom with a long table, seen through a glass wall

Enter it once. Every system has it.

Enterprise integration gets the systems you already run to agree on the same numbers. Most mid-market operations already have an ERP, a CRM, something on the floor or in the warehouse, and Xero for the books. Each works on its own, and people fill the gaps between them with exports and re-keying. Connect them and those hours come back, errors stop surfacing weeks late, and decisions are made on today's numbers.

What it costs you before anything is built

None of these appear as a line item. All of them are paid every month.

The hours in the gaps

Exporting, re-keying, reconciling. It is rarely anyone's full-time job, so it never gets counted. It goes a few minutes at a time, every day, across most of the team.

Decisions made on stale numbers

If the floor's output reaches the ERP the next morning, every decision made before it lands is made on yesterday's numbers, and the wrong call costs more than the wait.

The person who is the integration

There is usually one. They know which report to run, which column to ignore, and what the numbers mean when they clash. Nobody has written any of it down, so the day they go on leave, the numbers stop making sense.

Work you cannot take on

The manual layer scales with volume. Plenty of operations quietly decline growth because the admin behind it would not hold, which never gets recorded as a lost opportunity.

Integration problem or process problem?

One question decides it, before you spend anything: when two systems disagree, is there a right answer?

One right answer: connect them

One system holds the truth and the other should follow it. Connecting them removes the re-keying and the errors, and the payback shows up in hours.

Two right answers: fix the process first

Sales and operations count it differently. A connection would only automate the argument, so we say so in the workshop, not six weeks into a build.

How we decide which connection to build first

The first connection is rarely the obvious one.

Start where the same number is keyed twice, by two people, into two systems. That is where the hours are biggest and the payback easiest to prove, and it is rarely the connection everyone assumed was urgent. We find it by listing every export and re-key with the hours attached, which maps the real problem faster than an architecture review.

How an integration engagement runs

Map the manual layer (1–2 weeks)

Every export, re-key and workaround, with the hours attached and the person who owns it named. The roadmap comes out of this, and so does the honest answer about whether it is a process problem instead.

Two CodeFish team members in discussion across a meeting room table, one taking notes

Build one connection (3–6 weeks)

One connection, with a clear system of record, error handling and a log you can read. It runs alongside the manual process until the two agree, then the manual step stops.

A CodeFish developer working across three monitors, reviewing code and version history

Extend, and keep it standing

The next connection goes in once the first has held through a month end. Vendor upgrades get tested against every connection before they land, not after.

Four CodeFish team members working through a problem around a table of laptops, CodeFish Studio sign on the wall

What does enterprise integration cost?

Three steps, each priced before it starts, and you can stop after any of them. What moves the build price most is how your systems let us in: documented APIs keep the price down. Older on-premise systems cost more, because every vendor upgrade has to be re-tested.

Map the gaps

A fixed $9,000 + GST workshop maps every export and re-key between your systems and gives you a costed roadmap to take anywhere.

Prove one connection

A proof of concept through Ignite is fixed between $25,000 and $50,000, so you see one connection working on your own data before committing further.

Build it out

A full build through Amplify starts from around $100,000 and is quoted fixed price. Where your systems keep changing, ongoing work runs through Apex instead.

Integration questions we get asked

Usually not, and replacement is the more expensive way to find out. A system that mostly works and is well understood by the people using it is worth more than a better one nobody has learned yet. Replacement makes sense when a system is genuinely at end of life or the vendor is gone. That job belongs to an implementation partner. Our work starts once you have the systems and they have to talk.

Sometimes. A platform earns its licence when you have many connections that change often, because it gives you monitoring and retries without building them. For three or four stable connections it is usually cost without benefit. We will tell you which situation you are in, and we are not reselling anybody's platform.

It can break, and that is the main ongoing risk. We build against documented APIs where they exist, because those are versioned and deprecated with notice. Where we have had to reach in through a database, we say so up front and flag that upgrades need testing. Under an Apex partnership that testing is part of the work rather than a surprise invoice.

Some of them, and not the ones you are thinking of. A spreadsheet used for modelling or one-off analysis is fine and always will be. A spreadsheet that is the only record of something, or that has to be re-keyed into a system, is software pretending to be a document. Those are the ones worth replacing.

Three to six weeks after the workshop for the first connection, assuming system access and a named person on your side who can answer questions about the data. Getting API credentials from a vendor is the step most likely to add time, so we start it on day one.

Yes. We can work through a reporting database, a file drop or, at worst, a scheduled export we automate. It costs more, it is more fragile, and it needs testing at every vendor upgrade. We would rather quote that honestly than pretend the constraint is not there.

You do. Code, configuration and documentation are handed over as standard. Nothing we build between your systems locks you to us, and it should be readable by whoever picks it up next.

Probably not everywhere, and that is normal. Most integration projects stall on a data quality problem nobody owned before the project started, such as one customer recorded five different ways. The workshop looks at your real data, not just the system design, so the clean-up is scoped and priced before the build rather than found halfway through.

Ready to build something great?

Local partners, global standards – full service design and development.