Migrating a Regulated Legacy Application to Power Apps and Dataverse

Why is replacing a regulated legacy application different from an ordinary rebuild?

Because the old system is not just a set of screens. Over years it has absorbed eligibility checks, calculations, thresholds, approval routes and reporting logic that someone once agreed with a regulator, an auditor or a legal team, and much of it is no longer written down anywhere else. An ordinary rebuild asks users what they need. A regulated rebuild has to prove that the new system does what the old one did, or that every deliberate difference was decided and recorded.

The cost of getting it wrong is also different. A missed field on a sales form is a nuisance. A missed rule in a benefits calculation, a lending decision, a payroll deduction or a statutory report is a finding, a remediation exercise across affected records and sometimes a notification. That is why the assessment described on this page is a piece of work in its own right, done before anyone commits to a platform or a build budget. It is also technical guidance, not legal or regulatory advice: what counts as compliant comes from your compliance function and advisers.

How do you turn every regulatory rule into a testable specification?

Build a rule catalogue. Each rule gets a numbered entry that a developer can implement, a tester can verify and a compliance owner can sign. Rules come from three places: the regulation or policy itself, the legacy code and configuration, and the outputs the legacy system has produced for years. Where those disagree, record the disagreement rather than resolving it quietly.

When the rules are undocumented and the original developers have gone, recovering them from historical outputs is its own discipline, covered in our guide to migrating a legacy system with no original developers. This page assumes you are doing that work and focuses on the regulated shape of the catalogue.

Which rules belong in a deterministic server-side rule layer?

Any rule whose result has regulatory consequence, and any rule that must hold no matter how data arrives. On Dataverse, forms are only one of the ways records get written. Imports, integrations, Power Automate flows, the Web API and other apps write to the same tables, and logic that lives only in a form, a form-scoped business rule or client script does not run for those channels. A rule that matters has to run on the server, in one place, with the same result every time for the same inputs.

In practice that means synchronous Dataverse plug-ins for validation and calculation inside the transaction, and custom APIs backed by plug-in code for calculations that other processes call explicitly. Both are compiled, versioned, unit-testable code that deploys through solutions. Configuration still has a place for presentation and guidance, and Power Automate is right for orchestration, notifications and work that can happen after the transaction. What goes wrong is the same rule implemented partly in a business rule, partly in a flow and partly in a script, so that nobody can say which version ran for a given record. How to enforce a single rule reliably across every write channel, and the trade-offs between business rules, real-time workflows and plug-ins, is set out in enforcing compliance rules server-side before an audit.

What audit logging has to be defined before the first record is migrated?

Decide what evidence you will need to produce, for how long, and who must be unable to alter it, then design for that before migration starts. Dataverse auditing is not retroactive, so anything written before it is switched on for the right tables and columns has no change history. Migrated history needs its own treatment: the legacy audit trail either comes across as read-only records with their original dates, or the legacy system stays readable for the retention period.

• Which tables and columns need change auditing, and whether reads of sensitive records must also be logged, which is a separate capability from record change auditing.
• How long audit evidence must be kept, and whether the platform audit log retention you configure covers it or evidence has to be exported to storage you control.
• Who can delete or purge audit data. Administrators with the right privileges can delete audit logs in Dataverse, so where records must be tamper-evident, export them to write-once storage, for example Azure Storage with an immutability policy, and restrict that storage separately.
• A rule execution log for regulated calculations: rule ID, rule version, inputs, output and timestamp, written by the rule layer itself, so a decision can be explained years later even after reference data has changed.
• How approvals are recorded: approver, time and the state of the record they approved, not only a status change.

How should a parallel-run reconciliation be planned?

Both systems receive the same real inputs and compute their outputs independently, only the legacy system acts on them, and an automated comparison runs on a schedule with every difference explained and classified. For a regulated application the comparison is driven by the rule catalogue: each output under comparison maps to catalogue rules, so a difference points to a specific rule, input or reference value.

Plan it during the assessment, not the build. The inputs have to reach both systems, which may mean an interface or a controlled double entry, the comparison needs to be automated, and the exit criteria have to be agreed with compliance before the run starts, such as a number of consecutive cycles with every difference resolved. The daily mechanics, difference classification and cutover by process are covered in parallel running with daily reconciliation, and running controls across both systems while a wider estate moves is covered in consolidating legacy systems onto Dataverse.

What must a proof of concept prove before you commit to the build?

A proof of concept for a regulated replacement is not a demo of screens. It is a small, honest attempt at the parts most likely to fail, with pass and fail criteria agreed in advance. If it cannot pass, you have learnt that cheaply.

• The hardest rules pass: a handful of the most complex catalogue rules implemented in the proposed rule layer and passing every test case, including boundary and historical cases.
• Every write channel is covered: the same rules hold when the record is written through a form, an import, an integration and the Web API.
• The audit design works: changes, rule executions and approvals produce the evidence defined earlier, and the export to controlled storage runs.
• Reconciliation is feasible: a sample of real legacy inputs runs through the new rule layer and the automated comparison reports matches and explained differences.
• Security fits: the roles and segregation of duties the regulator expects can be expressed in the Dataverse security model without workarounds.
• Volume and timing hold: batch calculations and reports complete within the windows the business needs, within platform service protection limits.
• Residency and retention requirements are met by the environment region and storage choices, confirmed against current Microsoft documentation.
• Deployment is controlled: the proof of concept is built and moved between environments through solutions and a pipeline, not by hand.

What does Power Platform provide natively, and what still has to be designed?

Power Platform and Dataverse give a regulated application a lot out of the box, which is why they are often the right target. They do not make an application compliant by themselves. Microsoft revises feature names, retention options and regional availability, so confirm current behaviour in Microsoft documentation before relying on any item below.

Can HR and finance processes be built on Power Platform under regulatory reporting requirements?

The line-of-business processes around HR and finance often can: case and request handling, onboarding and offboarding steps, approvals, policy attestations, expense or grant applications, eligibility decisions and the reporting that sits over them. Built as Power Apps on Dataverse with a server-side rule layer and designed audit evidence, those are a good fit.

The ledger itself is a different matter. Solzet does not implement Dynamics 365 Finance or ERP systems. Where a regulated process produces postings, payments or payroll figures, we build the line-of-business application on Power Apps and Dataverse and integrate it with the finance system you already run, with reconciliation between the two, rather than rebuilding accounting on Power Platform. Regulatory reports that combine both should be defined against the finance system as the source of truth for financial figures. Sector context for banks, insurers and other regulated financial organisations is on our financial services page.

When is a custom build more defensible than Power Platform?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

For a regulated replacement, the question is which platform lets you evidence the controls most cleanly. A custom-built application on React, Node.js, PostgreSQL or .NET is the more defensible choice when the regulator or your own policy requires full control of hosting, database and backups; when records must be immutable at the database level rather than by application logic; when the rule layer is most of the system and the low-code parts would add little; when large numbers of occasional users make per-user licensing the wrong shape; or when change control must cover every line of the stack. Power Platform is usually the stronger choice when the organisation already runs on Microsoft 365, the application is mostly records, forms, approvals and reporting, and a focused rule layer can carry the regulated logic.

How does Solzet run a regulated migration assessment?

We run the assessment as a standalone engagement before any build commitment: the rule catalogue with test cases, the split between the server-side rule layer and configuration, the audit and retention design, the parallel-run plan and exit criteria, and a proof of concept against the criteria above. The output is a recommendation between Power Platform and a custom build that your compliance team can challenge, whichever way it lands. The build that follows is described in our Power Platform development service.

Solzet delivers remotely from Yerevan, Armenia, with senior consultants and full-stack developers and 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly or white-label for Microsoft partners. We provide technical design and evidence; regulatory interpretation stays with your compliance function and advisers.