Replacing a working tool is usually the expensive answer because the tool is the smaller part of the cost. The larger part is moving your data, rebuilding the habits and workarounds your team has built around it, and running two systems side by side while everyone adjusts. Connecting what you already have is usually cheaper and far less disruptive.
Integration means getting two tools to share information without someone retyping it. How hard that is depends on one question: how does each tool let information out and in? There are four answers, ranging from a proper API to no access at all, and which one you have decides what is sensible.
Why is replacing a working tool usually the expensive answer?
Because a tool that works has years of your business's habits built into it, and a replacement starts from zero. The price of the new subscription is the part you can see. The rest is not on the invoice.
- Migration. Moving old records into a new structure, deciding what to do with the ones that do not fit, and checking nothing was lost.
- Retraining. Your team knows where things are in the current tool, even if it is clumsy. They will be slower in the new one for a while.
- Hidden workarounds. Every long-running tool has unwritten conventions: the column that means "chase", the status nobody uses as intended. They disappear in a rebuild, and you find out when something goes missing.
- Running two systems. For a period, both are live, and people are not sure which one to trust.
We do not give figures for this because they depend entirely on the business. The direction is what matters: if the tool does its main job and the problem is that it does not talk to your other tools, replacing it solves a much larger problem than the one you have. A connection is the smaller fix.
How can two business tools be connected?
In one of four ways, and it is worth finding out which one each of your tools offers before anyone quotes.
An API. A published way for other software to read and write the tool's data directly. This is the best case: the connection can be reliable, can run as often as needed, and does not depend on a person remembering to do anything.
Webhooks. The tool tells another system when something happens, such as a new enquiry or a status change, instead of the other system asking repeatedly. Where available, they make a connection feel immediate and avoid constant checking.
Scheduled exports. The tool produces a file, often a spreadsheet, on a schedule or on demand, and something else picks it up. It is less elegant and often perfectly adequate. If the information only needs to be current once a day, a scheduled export can be the right design rather than a compromise.
No access. The tool offers no API, no webhook and no useful export. The data goes in and stays in. Be honest about this one, because it changes the answer.
Do not assume which of these a given tool offers, even a well-known one. Plans differ, features change and some access sits behind a particular subscription tier. Check the vendor's current documentation or ask them directly.
What does an integration actually involve?
Less than a rebuild, and more than a switch you flip. In outline, it involves five pieces of work.
- Deciding what moves. Which fields, in which direction, and what counts as the same record on both sides. A customer in one system has to be recognisable as the same customer in the other.
- Getting access. Credentials and permissions, ideally for a dedicated account, so the connection does not break when a person leaves.
- Mapping and tidying. The two tools almost never describe things the same way. Statuses, dates and names need translating, and inconsistent data needs a decision from someone in your business.
- Handling failure. What happens when a connection drops, a record is rejected or the same item arrives twice? An integration that works only on a good day is not finished.
- Keeping a record. What moved, when, and whether it succeeded, so a discrepancy can be traced.
- There is no access at all. No API, no webhook, no export you can use. If the tool's job is central to the workflow, you are retyping forever.
- Access exists but is deliberately closed. Some vendors restrict it to higher plans or particular partners, and the cost or terms are not worth it for your use.
- The tool is no longer supported. If it is not maintained, any integration is built on something that may stop working.
- It does not do the main job. If the real complaint is that it was never the right tool, connecting it will only make a poor fit faster.
- Screen-copying is the only option. Automating a tool by driving its screen can sometimes be done, but it is fragile and breaks when the screen changes. It is a last resort, not a plan.
- Which exact workflow. One path, from where it starts to where it ends, not "connect everything".
- What each tool offers. API, webhook, export or nothing, from current vendor documentation or a direct answer.
- What plan you are on. Access sometimes depends on it, and you want to know before a quote, not after.
- Who can grant access. The account owner, a vendor, an IT supplier. If it is someone you have not spoken to in years, find them now.
- How fresh the data needs to be. Instant, hourly or daily. This often decides between an API and a scheduled export, and it moves a quote more than most features. We went through the effect of that on price in what actually moves the price of a custom build.
This is why one existing-tool connection is a defined piece of work, not a fixed button. Our Automation Sprint covers one repeating workflow with integrations to existing tools, and the sensible first step is the same as for any build: write down the workflow as it actually runs. We set that out in what to write down before you ask for a quote.
When can a tool not be connected, and replacing it is right?
When it gives you no way to get your data in or out, and that is the thing costing you. Replacement is the right answer in a small number of honest cases.
Even then, replacing may be the second step. Getting your data out first, whatever the format, protects you whichever way you go.
Who owns the data in your tools?
Treat the data as yours and the tool as a place it currently lives, then check whether the tool lets you act on that. Ownership in principle is not the same as being able to get it out in practice.
Before relying on any tool for something important, find out three things. Can you export all your records, not just a report, and in a format another system can read? Does the export include the history and attachments, or only the current state? And what happens to your data if you cancel?
This matters for integration and for the future. A tool that lets you leave is a safer one to build around, because your work is not trapped by it. It also matters for software we build: you own the repository from day one, so what is built for you is not held hostage either. And if personal data is involved, a connection is a second place it is stored and a second place to protect, which is worth deciding before it is built rather than after.
What should you check before asking for an integration?
Five things, all answerable without technical knowledge.
With those answered, a developer can tell you what is practical in a single conversation instead of a week of guesswork.
When do you not need an integration at all?
When the two tools rarely need to agree. If information moves between them a few times a month, someone copying it carefully may be cheaper and simpler than any connection, and there is nothing wrong with that.
Likewise, if the underlying process is unstable, or if the real problem is that nobody owns a step, a connection will faithfully move the confusion from one tool to another. Fix the process first. And if one tool already does what you need with a small change to how you use it, ask whether the change is enough before paying for anything.
This is the order we work in at Ilumax Systems. We review your existing systems and the integrations they support before agreeing what is practical, aiming to reduce duplicate work and keep what already works. A single connection usually fits the Automation Sprint (S$4,800, two weeks, existing tool integrations included); portals and several integrations become a Custom Build with fixed-price milestones. Sometimes the review ends with advice to change a setting and build nothing, and we will tell you that too.
