There is a folder in the Training App repository called _powerplatform/. Inside it sit about forty Power Automate flows: practically all the logic of the application’s first version. It is marked read-only (which makes it the one folder in the repository guaranteed free of new bugs). Nobody runs them; they are read. I Changed Technology, Kept Only the Business Rules.
Training App was born in 2019, after our training business had grown quickly — and after a scare. Swell was then running thousands of trainees and trainers, events across the country, registrations and online courses from an Excel spreadsheet.
For quite a while, it worked. Then came scale, the requirements of DGERT certification, and the first operational problems.
With several training events running at once, a date error sent trainees to a classroom on the wrong day. Some had travelled to Lisbon specifically; I reimbursed their journeys.
The incident forced me to look at the spreadsheet differently. Where there were cells, there should have been rules. The rule “a session has a date, and everyone registered is notified when it changes” existed only in my head. My head does not scale, nor does it send emails.
From spreadsheets to rules
That year, the operating cycle of a certified training provider acquired a system. Courses, events, sessions, registrations, trainers and much of the technical and pedagogical dossier required by DGERT began to follow explicit rules.
The system ran on Power Platform: data in Dataverse, logic in Power Automate flows and interfaces in Power Apps. It served us for six years.
When we decided to turn the internal application into a product for other training providers, the problem changed in kind. An internal application tolerates shortcuts that a multi-tenant product cannot. Data isolation between clients, different commercial plans, licence management, access control and auditable compliance are not features to be added at the end. They have to sit in the foundations.
I underestimated that transition. Designing a product is considerably harder than building a good internal application.
In early 2026, I rebuilt Training App: PostgreSQL, Azure Functions and Next.js. Not a single line from the previous version runs in production today.
That does not mean we started again from zero.
Code became cheaper
There is a reason why this rebuild became economically possible. I did it without an engineering team. AI coding assistants have dramatically reduced the cost of producing the execution layer: the frontend, endpoints, tests, database migrations and infrastructure as code.
That gain matters, but I am more interested in what it did not do.
The assistants did not invent a single Training App business rule.
Those came from six years of operating a training provider and from the flows we had built as problems, exceptions and new requirements appeared. AI implemented them quickly because much of the work of discovering what the system should do had already been done.
Writing code became much cheaper. Discovering the right rules did not.
What survived the migration
Each Power Automate flow contained accumulated operating knowledge.
When a registration is confirmed, a contract is generated and a questionnaire is sent. When a session ends, attendance is recorded and the attendance rate recalculated. When an event closes, certain documents are produced in a defined sequence. There are dozens of rules like these, many accompanied by exceptions that only emerged after real cases.
During the rebuild, those flows became part of the specification.
One of the expensive parts of any migration is finding out what the old system actually does. In this case, much of that work was visible. The flows had been built slowly, over six years in production.
There was a practical problem. Power Automate presents its logic in a visual editor, which is not an ideal representation for a systematic agent-assisted migration. Rather than work from screenshots, I connected the repository to Power Platform and extracted the flows as JSON — the structured representation stored beneath the visual layer.
The agents could then analyse each definition, identify conditions, actions and dependencies, and help me reconstruct the rule in the new architecture.
That process revealed a second point: even a written rule retains an implicit residue. A flow may describe what happens under a particular condition without explaining why the condition exists, which historical exception created it, or whether it still makes sense. That part had to be discussed and clarified, rule by rule.
The real cost of archaeology
It is one reason very old systems survive for so long.
In 2017, Reuters estimated that around 220 billion lines of COBOL were still in production, supporting a substantial part of the world’s banking infrastructure. COBOL was introduced in 1959.
The explanation is not simply that banks like old technology. Decades of production software contain decades of solved exceptions, regulatory rules, conventions and decisions that may no longer exist anywhere else.
Replacing the code is only part of a migration. The archaeology consists of finding the rules buried inside it — including those whose existence nobody now knows about.
This is also the serious counter-argument to any rebuild. Fifty years in production means fifty years of solved edge cases. Replacing such a system carries the risk of removing a rule before anyone has even realised that the rule exists.
But that reinforces the central point: much of the accumulated asset is not in the syntax of the code. It is in the operating knowledge the code has come to embody.
An underrated advantage of low-code
Low-code has familiar costs: vendor dependence, architectural constraints and licensing models that can become expensive at scale.
But the Training App experience showed me an advantage that receives less attention: some of the operating logic remains relatively exposed. In Power Automate, specification and implementation sit unusually close together.
That does not automatically make a flow simple or well designed. Some flows are perfectly unreadable. But when the logic has been built with some discipline, it is possible to inspect the process, its conditions and its exceptions without beginning by excavating thousands of lines of software.
In my case, that visibility materially reduced the cost of the rebuild.
When a rule moves into the architecture
Not every rule returned to the new application in the same form.
Some were promoted.
Client isolation is one example. In the first version, several application rules helped ensure that each user saw the correct data. In the new version, part of that guarantee is enforced by the database itself through row-level security. A query returns only the active client’s data even if there is a defect higher up in the application.
The distinction matters beyond engineering. It is one thing for a software supplier to say that client data is separated; it is another for separation to be a technical property of the system itself.
An important rule may begin as an instruction inside a process. Once it is mature enough, some rules deserve to become properties the system cannot violate.
Where are your company’s rules written?
It is the question I now take into consulting projects before discussing ERP, CRM, applications or AI.
Where are the business rules written?
They may be in software. They may be in Excel. They may be in procedure documents nobody has opened for four years. And they may be in Fernando’s head, whom everybody calls when an unusual case appears.
If an important part lives only in the last place, the budget for the next migration will also be an archaeology budget.
The same problem now appears with AI agents. An agent allowed to recommend, approve or execute work needs to know the criteria, the exceptions, when to stop and who answers for the outcome. The more autonomy it receives, the less room there is for rules that somebody simply “knows how to apply”.
We did not start writing Training App’s rules because of architectural discipline. We started after a few mistakes had become expensive enough to force us to.
Six years later, the code we wrote then is gone. The rules remain.
