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.

An expensive system that does three things and fails audits: remediate it, move to Power Platform or build your own?

Stabilise first, decide second. When a costly subscription or legacy package does only three jobs, such as holding records, running an approval and producing a compliance report, and the last audit found problems with it, the instinct is to replace it before the next audit. That is usually the wrong order. A replacement takes longer than the time to the next audit, and an auditor wants the findings closed, not a promise of a new system. So triage the findings, close what can be closed in the current system, and only then make the platform decision, proven by a small pilot rather than a big commitment.

If the audit date itself is close and you need a compliant process in weeks, our guide to building a CRM in 60 days for an audit covers what is achievable against that kind of deadline. This section is about the decision that follows.

• Triage every finding into one of four groups. Configuration and access findings, such as shared accounts, missing approvals or excessive rights, can usually be fixed in the current system now. Data findings need a cleanup and a control to stop recurrence. Evidence findings, where the system cannot show who did what or export its history, may need a compensating control. Product findings are the ones the system genuinely cannot fix, and only those argue for replacement.
• Put compensating controls in place for anything you cannot fix this quarter: a documented manual check, a second approver, a reconciliation report, with an owner and a record that it ran.
• Secure your data before any decision: confirm you can export every record and its history in a usable format, check the contract notice period and renewal date, and take a complete export now so the vendor relationship does not decide your timetable.
• Write down the three things the system actually does, with the rules, reports and evidence each one has to produce. That list becomes the rule catalogue described below and the scope of any replacement.

What should a scoped replacement pilot prove before you cancel the old system?

That one of the three jobs can run on the new platform with the evidence an auditor wants, before you commit to moving the other two. Pick the job with the most audit findings or the clearest rules, build only that, and run it alongside the old system for at least one full reporting cycle, with every difference between the two explained. The old subscription stays until the pilot passes and the cutover plan is agreed, so the pilot never becomes a forced migration.

The exit criteria are written before the pilot starts: the job's rules pass their test cases, the audit trail answers the questions the last audit asked, the compliance report matches or the differences are explained, and users can do the work without a workaround. If the pilot fails those, you have learnt it cheaply and remediation of the current system becomes the better answer. Where the old system's rules are undocumented and the original builders have gone, our guide to migrating with no original developers covers recovering them and running the two systems in parallel.

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 and belongs in an ERP. Solzet implements Business Central and Finance and Operations for that side. 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 run, whether one of those or another, 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.

How do you replace a buggy home-built SharePoint HR system with Power Apps and Dataverse?

In four steps, in this order: stop the bleeding, build a minimum viable product of the HR processes that cannot fail, design a proper data model underneath it, and migrate one process at a time while SharePoint stays readable. Home-built HR systems on SharePoint lists usually start well and degrade as they grow: lists pass the list view threshold and views stop loading, lookups multiply until forms slow down, permissions are broken item by item to hide sensitive records, and flows written by someone who has since left fail silently. HR data is personal data, so a buggy system is a data protection problem as well as a productivity one. What follows is how we approach this work; the build itself is part of our Power Platform development service.

• Payroll stays where it is: the HR app integrates with the payroll system you run rather than replacing it.
• Keep SharePoint read-only, not deleted, until the retention period for the old records is agreed with HR and your data protection lead.
• Use Dataverse business units, teams and security roles so managers see their own people, HR sees everyone, and nobody relies on item-level permissions again.

Самописная система на SharePoint глючит: как заменить её на Power Apps и Dataverse?

Кратко на русском. Если самописная HR-система на SharePoint глючит, замену начинают не с разработки, а со стабилизации. Сначала остановите потери: заморозьте изменения в списках и потоках, сделайте резервные копии списков и библиотек документов, проверьте, кто видит какие кадровые данные, и отключите или исправьте потоки, которые падают без ошибок. Затем постройте минимальный продукт для двух-трёх критичных HR-процессов, например карточка сотрудника, приём и увольнение, заявки на отпуск с согласованием, как модельное приложение Power Apps. Под ним спроектируйте модель данных в Dataverse: сотрудники, подразделения, должности, заявки и согласования, с ролевой безопасностью и защитой чувствительных полей. Переносите данные по одному процессу, сверяя результат со старыми списками, а сайт SharePoint оставьте доступным только для чтения как архив. Зарплатный расчёт остаётся в вашей системе расчёта зарплаты, мы делаем интеграцию с ней. Мы работаем удалённо из Еревана и общаемся на русском и английском языках.

When is a custom build more defensible than Power Platform?

We recommend the right solution: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them.

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.