Microsoft’s documentation is blunt about it: the Regression Suite Automation Tool “is marked for deprecation and won’t be supported after May 15, 2027”. That line sits at the top of the RSAT overview on Microsoft Learn. The deprecated-features list adds the detail that matters most: asked whether RSAT is replaced by another feature, Microsoft’s answer is “No”.
From today that’s about 198 days. Most Dynamics 365 Finance & Operations teams will react to the RSAT deprecation the same way: pick a new tool, then try to move every test across. That’s the expensive way to do it.
An RSAT suite that has run for a few years carries more than tests. It carries recordings of forms that have since changed, derived test cases nobody remembers creating, chains that break if one link fails, and tests whose only check is that a page opened. Migrating all of that moves the debt into a new tool.
Don’t migrate your test debt. Triage it first.
This piece is the step before choosing an RSAT alternative: what’s actually in your suite, how to decide what to retire, merge or rebuild, how to pull the intent out of a recording, and a timeline that finishes before May 15, 2027. It also takes on the argument that AI agents can’t do deterministic regression testing, because that argument shapes which tools teams consider.
What’s Actually in an RSAT Suite
RSAT turns Task recorder recordings into automated tests, runs them through Azure DevOps and keeps test data in Excel. Before migrating anything, it helps to see the suite as separate assets, because they don’t all move the same way.
| Asset | Where it lives | What it holds | Migration note |
| Task recordings | A developer recording file attached to each Azure DevOps test case | The literal sequence of steps through the forms when it was recorded | The weakest asset. It records clicks, not intent, and ages with every UI change |
| Azure DevOps test plans and suites | Your Azure DevOps project | Test case IDs, organisation, run history and results | The best source of evidence for triage: what runs, what passes, what’s been ignored |
| Excel parameter files | Attached to each test case | Company and test user (General tab), step data and validation rows (TestCaseSteps), expected messages (MessageValidation) | Where most of the intent lives. Read these before the recordings |
| Validation steps | Added in Task recorder with Validate > Current Value, then in the Excel file | The expected values, with operators such as greater than from RSAT 1.210 | These are your real assertions. A test with none proves little |
| Derived test cases | Child test cases sharing the parent’s recording | The same task run with different data | Often the first place to merge or retire |
| Chained test cases | Variables passed between tests with Task recorder’s Copy function | End-to-end flows built from several recordings | A dependency map you’ll need to rebuild as one process test |
| BPM libraries (optional) | Lifecycle Services | Test libraries shared across projects and tenants, mostly by partners and ISVs | Export what you need; not every team uses BPM |
The pattern is worth noticing. The recording is the part every tool vendor talks about importing, and it’s the part with the least lasting value. What you actually need to keep is in the validation steps, the parameter files and the chains: what the test expected to be true, with which data, in which order.
If you’re still weighing why RSAT suites become hard to maintain in the first place, our piece on RSAT’s limitations covers it.
Step 1: Take an Inventory Before You Touch a Tool
Start with a spreadsheet, not a vendor demo. Export your Azure DevOps test plans and pull every test case into one list. The RSAT command line helps here: commands such as listtestplans, list and download retrieve test cases and their recording, execution and parameter files.
| Column | Where it comes from | Why you need it |
| Test case ID, title, suite | Azure DevOps | The key everything else hangs on |
| Business process and module | Test title, BPM, or the owner | Prioritizing by risk later |
| Last run date and pass rate (last 6 months) | Azure DevOps test runs | Spotting tests nobody runs or everyone ignores |
| Number of validation steps | The Excel parameter file | Separating real tests from click-through |
| Derived children and chain dependencies | Azure DevOps and the parameter files | Knowing what breaks if you remove or merge one |
| Owner | Your team | Someone who can say whether the process still exists |
Two afternoons with this list usually changes the size of the problem. It’s also the document an auditor will want later, if you’re RSAT tests ever served as evidence for a control.
Step 2: Triage Every Test Into One of Four Buckets
Not every test deserves to survive the move. Sort each one into a bucket using evidence from the inventory, not memory.
| Bucket | Signs a test belongs here | What to do |
| Retire | Hasn’t run in six months or more; covers a process you no longer use; duplicates another test; has no validation steps at all; or is really a unit or data-integration test | Archive the files and record why. Microsoft’s own guidance says not to use RSAT for unit tests (use SysTest and the Acceptance test library) or data integration tests (use the data management framework), so those belong elsewhere anyway |
| Merge | Derived test cases whose data differs only trivially; chains of small tests that together form one business process | Combine into one process test with a few meaningful data variations |
| Rebuild | A business-cycle test on an important process, with real validation steps and a decent pass history | Carry the intent across as it is (step 3) |
| Rebuild and strengthen | A critical process whose test only checks a field on screen or a message, not what was posted | Carry the intent across and add outcome assertions: the voucher posted, the ledger amounts, the inventory change |
Be strict with the first bucket. A test that hasn’t run since a release wave two years ago isn’t coverage; it’s a file. Retiring it is a decision, so write the reason in the inventory and let the process owner sign it off.
Step 3: Extract the Intent, Not the Clicks
For every test you keep, write down what it was really checking, in business terms. The recording tells you the route; the parameter file and validations tell you the point. An example:
| RSAT artefact | What it says | The intent to carry across |
| Recording | Open purchase order form, select vendor, add line, confirm, post product receipt | Route only; don’t copy it step by step |
| General tab | Company USMF, test user AP clerk | Run in that legal entity, as a user with that role |
| TestCaseSteps | Vendor 1001, item A0001, quantity 10 | Starting data, which you need to keep stable |
| Validation rows | Total available greater than 0 after receipt | On-hand inventory increases by the received quantity |
| Message Validation | Posting message text | The posting succeeded, ideally confirmed in the data rather than the message |
| Chain variable | Purchase order number passed to the invoice test | The same order is invoiced next, so it’s one process test, not two |
The result is a short intent statement for each test: the process, the starting data, the user role, and what must be true in Dynamics 365 afterwards. That statement is what you migrate. It works in any tool, and it’s the thing that was missing when the recording broke after the last UI change.
Stable starting data matters as much as the steps. Our piece on test data management for AI agents covers keeping it clean between runs.
Step 4: Rebuild by Risk, and Run Both Suites in Parallel
Rebuild in order of business risk, not in the order tests appear in Azure DevOps: period close and financial postings first, then order-to-cash and procure-to-pay, then everything else. For finance processes, the assertions worth adding are on what posted, which our guide to Dynamics 365 Finance agent testing covers in detail.
Then run the new suite alongside RSAT until the new one has proved itself, through at least one Microsoft update. Retire each RSAT test only when its replacement has passed the same scenario. RSAT end of support leaves room for that, but not much:
| When | Work | Done when |
| November–December 2026 | Inventory and triage | Every test is in a bucket, with retirements signed off |
| January–February 2027 | Extract intent and rebuild the highest-risk processes | Finance and order-to-cash tests run in the new tool |
| March–April 2027 | Rebuild the rest; run both suites in parallel, including through Microsoft’s spring update | New and old suites agree on every kept scenario |
| 1–15 May 2027 | Buffer, then switch off RSAT runs | Nothing in the release process still depends on RSAT |
If that plan already looks tight, it’s a sign to start the RSAT migration now rather than in the spring.
“But Regression Testing Needs Determinism”
The strongest argument against using AI agents to replace RSAT goes like this. In an August 2026 article on ERP Software Blog, Aaron Glidewell of TheTestMart wrote that “Agents and LLMs are probabilistic technologies” while “Regression testing is deterministic by design”, and that “an agent that executes a test differently this cycle than it did last cycle” can’t give you a reliable regression result.
Half of that is right, and it’s the important half. A regression test needs a fixed expectation: the same starting data, the same expected outcome, and the same rule that a different outcome is a defect. The article puts it well: “If the inputs are the same and the outcome changes, there is a defect.”
Where it goes wrong is in assuming the route has to be fixed too. An RSAT recording fixes the route, which is exactly why it breaks when a form changes and nothing about the business outcome did. What needs to be deterministic is the assertion, not the path to it.
The route can vary. The assertion on the outcome can’t.
- Fixed: the starting data, the user role, and the expected outcome in Dynamics 365, such as the voucher, the ledger amounts and the inventory change.
- Allowed to vary: which buttons were clicked to get there, when a release wave moves a field or renames an action.
- Recorded every run: the route actually taken, so a reviewer or auditor can see how the outcome was reached.
The same article accepts AI for authoring tests and self-healing scripts, and self-healing already means the route changes from run to run. The real line isn’t between deterministic scripts and probabilistic agents. It’s between tests that assert on outcomes and tests that only replay steps, and an RSAT recording with no validation rows is the second kind.
Where Sofy Fits
Sofy’s RSAT migration page describes a Conversion Agent that moves your critical test cases across automatically and turns RSAT workflows into agent-led tests. It says business process knowledge is preserved and gaps are identified before migration, which is the triage this piece describes, done with the suite in front of you.
On the Dynamics 365 side, Sofy’s Dynamics 365 test agents validate journals, AP/AR, dimensions, posting logic and period close in Finance, adapt automatically on every release wave without re-recording, and run from Azure DevOps pipeline triggers, so the rebuilt suite fits where RSAT ran.
PLANNING YOUR RSAT MIGRATION?
See how Sofy’s Conversion Agent turns RSAT workflows into agent-led tests, and what it flags before you migrate.
What Still Needs a Human
Triage is a business decision dressed as a technical one. Whether a process still exists, whether a test was evidence for a control, and whether a weak test should be strengthened or dropped all need the process owner, not just the QA team. No tool should retire a test on its own.
The same goes for the intent statements. A recording can’t tell you why a validation was there. Someone who knows the process has to confirm that the expected outcome you’ve written down is still the right one.
Frequently Asked Questions
When does RSAT support end?
Microsoft says RSAT is marked for deprecation and won’t be supported after May 15, 2027. Its deprecated-features list gives the same date and says RSAT isn’t being replaced by another feature.
Does Microsoft provide a replacement for RSAT?
No. Microsoft’s guidance points to SysTest and the Acceptance test library for unit and component tests, and the data management framework for data integration tests. For business-cycle regression testing, which is what most RSAT suites do, you’ll need another tool.
Can I import RSAT task recordings into another tool?
It depends on the tool, and some vendors don’t document a direct import. Even where an import exists, a recording captures clicks rather than intent, so the safer path is to migrate the intent: the starting data, the user role and the expected outcomes held in the Excel parameter files and validation steps.
Which RSAT tests should I retire instead of migrating?
Tests that haven’t run in six months or more, cover processes you no longer use, duplicate other tests, or have no validation steps. Unit and data-integration tests shouldn’t be in RSAT at all, according to Microsoft, so move them to the right framework instead.
What happens to my Excel parameter files?
Keep them. They hold the company, test user, step data, expected values and expected messages for each test case, which is most of what you need to rebuild a test’s intent in a new tool. Export them with the rest of the test case before support ends.
Can AI agents run deterministic regression tests?
Yes, if determinism sits in the right place. The starting data, the expected outcome and the assertion stay fixed from run to run; the route through the UI can adapt when forms change, and it’s recorded each run. A different outcome from the same inputs is still a defect.
The Bottom Line
May 15, 2027 isn’t far away, and Microsoft isn’t shipping a successor. The teams that come through it well won’t be the ones that converted every recording fastest. They’ll be the ones that knew what was in their suite, retired what wasn’t earning its place, and carried the intent of the rest into tests that assert on outcomes.
Take the inventory this month. Triage before you choose a tool, and rebuild in order of risk. The recordings were always the least important part.