Think Build Implement Repeat
Data & Scraping

Getting Data Out of a System Nobody Wants to Touch

Last updated:

The system everyone is afraid of

Most established businesses have one: old, critical, poorly documented, maintained by a vendor who has lost interest or by nobody at all. It holds data everything else needs.

The instinct is to leave it alone. The practical need is to get data in and out without destabilising it, and there is a clear preference order for doing so.

The options, best to worst

  1. Official API. Supported, documented, safe. Ask the vendor even if you assume the answer is no.
  2. Supported export and import. Scheduled files. Unglamorous, low risk, adequate for most reporting and sync needs.
  3. Read-only database replica. Excellent for reporting with zero risk to the live system, provided you understand the schema.
  4. Direct database writes. Only with vendor blessing and real understanding. Business logic often lives in the application, not the database, so writes can create records the application considers invalid.
  5. Screen automation. Last resort. Fragile, breaks on any interface change, and needs constant attention.

Read is safe, write is not

Reading from a legacy system is a low-risk project. Writing to one is a different category of work, because you are asserting that you understand rules that may never have been written down.

Where writes are necessary, prefer the application's own import mechanism, which applies the same validation a user would trigger.

Protect the live system

  • Never develop against production — take a copy
  • Rate limit your queries; old systems are frequently fragile under load
  • Run heavy extraction outside business hours
  • Monitor the legacy system's performance during rollout, not just your own
  • Have a way to switch the integration off instantly

Document what you learn

Working out what a legacy schema means is expensive and it is knowledge that otherwise leaves with whoever did the work. Write it down as you go: what each important table holds, which fields are actually used, and which are relics.

That document frequently becomes the most valuable output of the project, particularly if replacement is on the horizon.

Frequently asked questions

Is screen automation ever acceptable?

As a bridge, with eyes open: expect it to break, budget maintenance, and treat it as temporary. As a permanent architecture it accumulates cost quietly.

What if the vendor forbids integration?

Check the contract, and weigh it commercially. Sometimes the honest conclusion is that the vendor lock-in is itself the reason to plan a replacement.

What does legacy integration cost?

Read-only extraction for reporting typically £8,000–£20,000. Bidirectional integration with a poorly documented system is considerably more and should be scoped after investigation, not before.

Should we just replace it?

Only on the usual criteria: unsupported, unable to express the business, or workarounds costing more than replacement. Integration first is usually cheaper and lower risk.

Keep reading

Data locked in a system nobody dares touch?

Reading from it safely is usually easier than expected. Tell us what it is and we will tell you the least risky route in.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Web ScrapingData Science