We build automation that moves data between two systems on an ongoing basis — a recurring import, a scheduled export, a sync running on a timer — and because this keeps running after we leave, ownership matters here just as much as with any other persistent automation: what happens if one of the two connected systems changes, or the automation simply stops.
Two systems means two ways this can eventually break
Unlike a script touching only your own site, this automation depends on two separate systems staying compatible with each other — either one changing its data format, API, or access requirements can break the sync. We’ll build it to your current spec and document how to recognise a failure, but a future change on either connected system’s side is a new problem at that time, not something covered indefinitely by this setup.
Import & export automation between systems
Ongoing sync between two systems, documented plainly for what happens if either one changes.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- A clear spec of what data should move between which two systems, and on what schedule
- Access or credentials for both connected systems, scoped appropriately rather than full account access where possible
- Confirmation of who should be notified if the automation fails, and how
This or something else?
| You want ongoing, scheduled automation moving data between two specific systems | This fix covers it |
| You have a one-time data transformation or migration, not an ongoing sync | Bulk data transformation script, the one-time version |
| You want a Zapier or Make scenario specifically, using those platforms rather than custom code | Zapier scenario build from supplied spec, or Make (Integromat) scenario build |
| An existing import/export automation has stopped working | Worth describing the specific failure directly — likely a diagnostic fix rather than a fresh build |
What we do
- Confirm the exact data, direction, and schedule for the sync
- Build the automation connecting both systems
- Configure failure notification to your specified recipient, where feasible
- Test with real data to confirm accurate, complete transfer
- Verify the automation handles a reasonable range of expected data variation correctly
- Provide written documentation covering what it does, its schedule, and what to do if either connected system changes
What is included
- Ongoing, scheduled data automation built between your two specified systems
- Failure notification configured where feasible
- Verified accurate, complete data transfer with real data
- Written documentation on ownership and failure response
Not included
- Ongoing, indefinite monitoring of the automation’s continued success by us — that responsibility transfers to you
- Fixing the automation if either connected system changes its own API or format in future, unless engaged separately at that time
- Zapier or Make-based automation, if you’d rather use one of those platforms instead of custom code
- Guaranteeing indefinite compatibility between the two connected systems as either evolves independently
Questions about this fix
What happens if one of the two systems changes its own API?
That's a genuine, ongoing risk with any integration between two independently maintained systems — if it happens, the automation would need to be updated to match, which is a new, separate piece of work at that time rather than something an initial build can guarantee against indefinitely.
Who's responsible for noticing if this stops working?
You are, ultimately — we build in failure notification where feasible and document how to recognise a problem, but ongoing responsibility for noticing and acting on that notification transfers to you once the fix is delivered.
Is this more reliable than using Zapier or Make for the same thing?
Custom code can be more efficient and tailored to exactly your needs, though a platform like Zapier or Make offers a more visible, sometimes more maintainable interface for someone without direct code access — the right choice depends on your specific situation and technical comfort.
Will this handle unusual or unexpected data correctly?
We test against a reasonable range of expected variation, though genuinely unusual data outside what was anticipated in the original spec could cause unexpected behaviour — worth flagging any known edge cases upfront so we can account for them.
What access do the two systems actually need to give this automation?
We'd request the most limited, appropriately scoped access that accomplishes the task for each system, rather than full account access, wherever the systems' own permission models support that distinction.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.