What I automate / Data moving between systems
When a person is the integration
Two systems that will never be integrated by their vendors, and a person in the middle doing it by hand. Exporting a file from one at the end of the day, tidying it, importing it into the other, and fixing whatever the import rejected. It is the single most common automation request there is.
It is also the one most likely to be silently wrong. Manual transfer has no record: when a row goes missing, nobody knows whether it was never exported, rejected on import, or typed in wrong. The error is found weeks later, in a reconciliation nobody enjoys.
Automating it does two things. It gives the hours back, and it gives you a log — what moved, when, and what was refused and why.
You probably know this is you if
- Somebody exports from one system and imports into another as a daily or weekly ritual
- The same record is typed into two places, and the two drift apart
- A file arrives by email every morning and somebody has to do something with it
- When a record goes missing, nobody can say at which step it was lost
- Your vendor has said integration is not possible, and that was the end of the conversation
The jobs in this area
Exporting from one tool to import into another
The two systems talk directly on a schedule, with a record of what moved and what was rejected.
Typing the same record into three places
Entered once, written everywhere it is needed, with the copies kept in step afterwards.
A CSV that arrives by email every morning
Picked up, validated and loaded on its own — and if the file is late or malformed, you hear about it rather than discovering it later.
Legacy software with no integration
If it can export a file, print, or expose a database, it can usually be automated around without touching the software itself.
Silent failures nobody noticed for a week
Every run logged with a result, and a message when a run fails or simply does not happen.
How a build like this goes
- 1
Work out what each side can actually do: an API, a scheduled export, a database you can read, a shared folder, an email attachment. There is almost always something.
- 2
Agree what happens to a record that cannot be transferred. This is the decision that matters — rejected rows must go somewhere a person will look, not into a log nobody reads.
- 3
Build the transfer with a record of every run: how many rows, how many accepted, how many refused and why.
- 4
Then the part people forget: an alert when the job fails, and an alert when the job simply does not happen, which is the failure mode nobody notices for a fortnight.
A worked example
Orders from the sales system into accounts
- Before
- Every evening, export, tidy in Excel, import. Forty minutes, and a monthly reconciliation to find what went missing.
- After
- Runs hourly. Rejected rows land in a sheet with the reason, and the person who used to do the transfer now only looks at those.
40 minutes a day × 5 days × 52 = about 173 hours a year, plus a day a month reconciling. Comfortably a module-band job, and the reconciliation day usually disappears entirely — which is the saving people underestimate when they only count the transfer time.
Those are illustrative figures, not a quote and not a promise. Your own numbers are the only ones that matter — the calculator does the same arithmetic on them.
What this normally costs
A job in this area is usually a connected module: ₹60,000 to ₹1,80,000, two to four weeks. The exact number comes from the audit, in writing, before anything is built.
The audit itself is ₹9,999 and comes off the first build in full. If it turns out this is not worth automating for you, that is what the report will say.
Questions about this kind of work
Will this break our software support contract?
Not if it is done properly. Reading exports, using a documented API, or reading a replica database does not modify the vendor's software. I will not make undocumented writes into a vendor's database, and you should refuse anyone who offers to.
How often should it run?
As rarely as the business genuinely needs. Hourly is usually plenty and fails more gracefully than real-time. Real-time is occasionally necessary and always more expensive to build and maintain.
What if the systems disagree about a record?
We decide up front which system is the source of truth for each field, and the automation never silently overwrites the other. Conflicts go to a person.
Tell me about your version of this
Tell me the job you are tired of
One call, half an hour. You will get a straight answer about whether it is worth automating — including 'no' if that is the answer.