Practical guide
Every company that has existed for more than a decade has at least one system nobody wants to touch. An old accounting module, an ERP installed in 2008, an in-house app whose vendor disappeared, a government portal that looks like it was built in primary school. Classic API integrations are out of the question – there's nothing to integrate against. This is exactly the area where RPA delivers the most value. This article shows what automating such systems looks like in practice.
Every digital transformation discussion contains the suggestion just replace the legacy. In practice that's much harder than it sounds. Replacing the central ERP in a 200-person company is typically a 2–3 year project on a multi-million budget. Replacing the accounting module – over a year. Replacing a homegrown app – even longer, because there's no standard replacement.
Reasons legacy systems stick around: the cost of replacement is often higher than the value it brings. Historical data is too complex to migrate. The team knows the old system and resists change. The vendor of the new one won't guarantee it handles all your edge cases. All of these reasons are real.
So in a typical company with 15 years of history, modern tools (M365, monday.com, SaaS CRM) live alongside a handful of legacy systems: the main ERP, the warehouse system, the HR system, an in-house production app. Each handles a slice of the process, and data flows between them by hand.
And this is where RPA shows its real value. The robot doesn't ask the vendor of the legacy system for an API. It doesn't wait for an update. It doesn't require change of any kind. It just logs in like a human, clicks what a human clicks, types what a human types. It works.
Scenario one: an old accounting module. A classic – older versions of Polish/European accounting packages, sometimes products from vendors that no longer exist. Daily invoice entry, generating reports, exporting data to the bank. The robot logs in in the morning, opens the invoice registration module, enters the data one by one. Runs unchanged for years.
Scenario two: a government portal. Checking application statuses, downloading certificates, submitting documents. Tax authority portals, social security portals, court registries, official e-government portals – they all share one trait: built for a human clicking, not for a system exchanging data. RPA fits perfectly – it logs in, clicks, downloads, saves.
Scenario three: a homegrown corporate app. Every manufacturing and trading company has a program written by someone who left long ago. It handles production, the warehouse, industry-specific processes. No documentation, code unavailable, vendor gone. RPA is often the only way to integrate such an app with the rest of the company.
In all three scenarios, classic integration tools (Power Automate Cloud, n8n) are powerless. They have no connectors for these systems because the systems offer nothing to connect to. RPA is the tool made for exactly this.
A paradoxical observation most companies don't expect: robots on legacy systems are more stable than robots on modern apps. The reason is simple: legacy systems don't change.
A classic ERP installed in 2010 looks exactly the same as it did then. Fields in the same place, buttons the same colour, screen layout identical. A robot trained on that system runs untouched for years. The vendor doesn't release updates because the system is on its last legs – which, from the robot's point of view, is excellent news.
Modern SaaS apps, on the other hand, refresh the UI every few weeks. New graphic design, new button locations, new field order. Every such change breaks the robot and someone has to patch it. Over a year a robot on SaaS may need 5–10 fixes, while a robot on the old ERP needs none.
Second advantage: legacy systems are often simpler. One window, a few fields, one button. The robot learns them in hours. Modern SaaS is richer – multi-step user flows, modals, animations, lazy loading. A robot on such a system needs much more developer work.
Practical conclusion: if a company is torn between RPA on a legacy ERP or on a modern SaaS – the legacy ERP is often the better choice. Less work, more stability, longer value from the deployment.
Manufacturing company, 150 people. Central ERP installed in 2009. The vendor long stopped developing it, but the company sticks with it because migration to a new ERP is an 18-month, half-a-million-euro project. Meanwhile, invoice entry takes two accountants 3 hours a day each.
Solution: an RPA robot. A Power Automate Cloud workflow picks up invoices from the company mailbox. OCR (Microsoft Document Intelligence) extracts numbers, dates, amounts, tax IDs from the PDFs. Power Automate hands the data over to a Power Automate Desktop robot. The robot logs into the old ERP, opens the invoice registration module, fills in the fields one by one, attaches the PDF, saves. The whole flow for one invoice – 45 seconds.
Deployment: 6 weeks of work, around 8,000 EUR. The robot processes 90 invoices a day, running overnight. In the morning the accountants see a report with about 8–10 exceptions needing a decision.
Effect after 12 months. Accountants' time shifted from invoice entry to cost control, audits of suspicious transactions, supplier conversations about corrections. ROI in 6 months. The old ERP can live for another 5 years; the company has time to make a thoughtful choice about a modern system.
This isn't a hypothetical story – it's the typical scenario for hundreds of manufacturing companies. RPA on a legacy ERP is often the cheapest path to automation value.
Old systems don't disappear on their own. You can replace them – slowly and expensively. Or you can add a robot layer that quietly does what the team used to do by hand. Each approach has its place.
Government portals are a separate category. Often no API. Often card or trusted profile login. Often captchas and anti-bot protection. All of that makes automation here harder than on regular apps.
But it's possible – and often necessary. Checking case statuses. Downloading certificates. Submitting documents. Daily tax-ID verifications of suppliers. All of this can be done with a robot, just with more careful design.
Key principles. First, the robot always logs in as a specific employee (with their consent), not as an anonymous bot. Second, the robot respects portal limits – no spamming, no attempts to bypass captchas, runs during business hours. Third, the robot keeps full logs of its actions so an audit trail exists.
Practical examples. A robot verifies VAT status of suppliers every day. A robot downloads new certificates of no arrears the client contracts require. A robot checks court case statuses every day for the legal team. Each saves several hours a week and does it more reliably than a human.
Important: always read the portal's terms. Some portals officially forbid automated access. In those cases look for another route (e.g. an API if available in an enterprise tier) or skip automation.
Homegrown corporate apps written years ago by someone who has long left are often the toughest RPA cases. And the most valuable – because outside of RPA, there's no other route.
Typical example. A manufacturer has a Delphi 7 desktop app from 2002. It runs the entire production planning – orders, deadlines, raw materials. The vendor is gone, source code exists but nobody can change it. Anything new the company wants to do with this data has to flow through manual copying out of the app.
Solution: an RPA robot on this app. The robot learns clicking around its windows. Pulls order data, exports to Excel. Other company workflows read that Excel and pass the data along. Not elegant, but it works – and often that's enough.
Specifics of such deployments: time. A robot on a homegrown app usually takes more configuration work than a robot on a popular system. The paths have to be mapped carefully, exceptions anticipated, behaviour planned for app freezes. Deployment takes longer, but then runs trouble-free for years.
Such a deployment often lets the company postpone the replacement of the homegrown app by years. The robot fills the gaps, exports the data, integrates the app with the rest of the company. Meanwhile the company can plan the replacement calmly – without panic, without rush.
RPA shows its real value where classic integrations are powerless – on legacy systems, government portals and homegrown apps without support. Environments where robotization doesn't compete with APIs, because there are no APIs.
Paradoxically, robots running on such systems are often more stable than robots on modern SaaS. Legacy systems don't change, so a robot once trained runs untouched for years. That makes legacy RPA one of the fastest-returning investments.
Typical scenarios: an old accounting module, government portals, a homegrown corporate app without vendor support. In each, RPA can take over the daily routine and free the team for more valuable work.
An extra advantage: RPA on legacy buys the company time. Instead of rushing replacement decisions, you can automate the worst pain points and plan the strategic replacement calmly. See also RPA vs API integration and Why companies still copy data manually despite RPA.
About this page
About the author
Kacper Włodarczyk
Założyciel ALGORCOMP
Założyciel ALGORCOMP. Specjalizuje się we wdrożeniach Microsoft 365 Copilot, Copilot Studio, Power Platform (Power Automate, Power Apps, SharePoint) oraz agentów AI dla średnich firm B2B w Polsce. Prowadzi dziesiątki projektów z zakresu strategii AI, governance Power Platform, automatyzacji obiegu dokumentów i procesów sprzedażowych. W publikacjach koncentruje się na praktycznych aspektach wdrożeń AI w organizacjach — od pierwszego POC do skalowania na całą firmę, ze szczególnym uwzględnieniem bezpieczeństwa danych, zgodności (RODO, NIS2, AI Act) i zwrotu z inwestycji.
Meet the teamFree 30-minute conversation. We look at the legacy systems in your company and tell you honestly where RPA can handle them and where it's better to plan a replacement. No selling one tool.
Featured
What an RPA robot actually does after working hours. A plain-language tour of what a robot really does step by step, and the kinds of work it handles in companies – invoices, data from portals, reports, transfers between systems.
RPA executes, AI decides – it sounds simple, but in practice companies confuse the two and end up picking the wrong tool. A clear, jargon-free walk through where the robot ends and the AI begins, and how to combine them.
Not every process is a fit for a robot. How to spot the ones that pay back fastest and what to ask yourself before launching an RPA project at all. A readable shortlist, no technical jargon.
