Start from what the system allows
For an old program, first assess which access paths it admits, from best to worst: a documented API, a scheduled data export, reports generated at fixed times or, as a last resort, reading its screen. Some systems admit no viable path. The order matters: each level down adds fragility.
Before designing anything, answer with facts: does it have an API and who authorises its use? Which exports does it support and how often? Is there documentation or a person who knows it? Without these answers, any proposal is a gamble.
API versus export versus screen
The API is the solid path: defined access, per-operation permissions and clear errors. If your system has one, use it. Export (CSV, Excel, shared folder) is honest and enough for many cases: an agent or automation consults the updated copy without touching the original system.
Screen automation (opening the program and simulating clicks) can be fragile: visual changes may break it, and it is hard to audit. Before raising it, check licensing, authorisation and failure modes with the accountable person. It is only raised as a last resort, with its risks explained and a person supervising.
- Authorised API: direct connection, permissions and clear errors
- Scheduled export: an updated copy without touching the original
- Fixed-time reports: enough when data is not urgent
- Screen: last resort, fragile and always supervised
Limited permissions in phases
Connect in phases and with the least permission possible. First phase: read-only (checking stock, finding customers, reading states). Second phase: preparing actions a person confirms. Only afterwards, and where the record justifies it, executing bounded low-risk actions.
Each phase needs its own observation period: what was consulted, what failed and what escalated. Without records there is no improvement, and without phases you cannot tell what broke what.
Human validation is non-negotiable
Legacy data tends to hold duplicates, mixed formats and fields meaning different things depending on who entered them. No agent should act on them without validations: completeness, reasonable ranges and alerts on the unexpected.
Define from the design what needs human approval: amounts, deletions, customer communications and any irreversible change. What the system moves alone must be reversible and stay recorded.
When not to connect
Some systems admit no reliable connection: no API, no orderly export and unstable screens. In that case the honest advice is not to invest in the connection and to seek alternatives: orderly coexistence, partial data migration or replacing the specific module.
If a proposal promises to connect any system without assessing it, ask for the assessment in writing before signing anything.