, its task-recording-based regression automation tool for Dynamics 365 Finance and Operations, will reach end of support on May 15, 2027. For many teams, this has created an urgent need to evaluate alternative testing solutions.
Why RSAT?
Companies chose RSAT because it was native to Finance and Operations and did not require a separate test automation platform license.
RSAT enabled functional power users to record business processes with Task Recorder and convert those recordings into automated tests without writing source code. There was a high degree of maintenance involved, but for many teams, the benefits outweighed the cost.
Now What?
Microsoft made it plain and simple in its announcement, and those of us in the space have shared it many times:
The Regression Suite Automation Tool (RSAT) is marked for deprecation and won't be supported after May 15, 2027.
Dynamics 365 Finance and Operations customers are . That makes regression testing an ongoing operational requirement. Completing those test cycles manually requires significant time and resources and can disrupt the business for weeks at a time.
As teams look to replace RSAT, they will find several options, each with its own strengths and tradeoffs. The choices include open-source frameworks, purpose-built platforms, and AI-assisted approaches. Here is a breakdown of each.
Open Source
Open-source tools such as and have been available for many years. Test engineering teams were building stable, reliable, and flexible automation with these frameworks long before RSAT was deprecated.
For teams replacing RSAT, the first similarity they may notice is the price.
Open-source frameworks are free, at least at the software-license level.
Teams can download the packages, install them in a development environment, and begin building tests. However, production-grade open-source automation generally requires coding and test-engineering skills. Although tools such as Playwright provide interfaces for generating, running, and debugging tests, the tests themselves are code-based and require technical expertise to maintain.
Maintenance also requires the ability to troubleshoot both the application under test and the Selenium or Playwright code.
The framework is only one part of the cost.
Playwright tests must run somewhere. Cloud-hosted browsers and CI runners may charge based on execution time or capacity. Running tests in parallel may also require additional runner or cloud-browser resources. Teams that self-host avoid some usage fees but assume responsibility for providing, scaling, securing, patching, and supporting the infrastructure.
Test execution can also generate reports, screenshots, videos, traces, and other artifacts that consume storage. Failed tests and retries consume additional execution time. Some organizations may also need separate tools for enterprise test management, reporting, and test-data management.
The software may be free to download, but building, running, and operating a reliable enterprise testing capability is not.
Purpose-Built Test Automation Platforms
Another option is a purpose-built test automation platform. Many specialize in particular systems under test. Salesforce has platforms designed to support Salesforce, NetSuite has platforms designed to support NetSuite, and Dynamics 365 has a set of designed to support Dynamics 365.
These platforms generally have a lower technical barrier to entry than open-source frameworks. Much of the underlying infrastructure for authoring, executing, and reporting on tests has already been built. Depending on the product, business users and functional consultants may be able to create and maintain tests without writing code.
That does not eliminate the need for testing expertise. The organization still needs to determine what should be tested, define the expected results, manage test data, investigate failures, and maintain coverage as business processes change.
Security should also be part of the evaluation. Testing platforms may use application credentials, interact with sensitive or production-like data, and retain screenshots or other execution evidence. Organizations should understand how credentials and data are protected, how access is controlled, what audit history is available, and whether the platform can satisfy internal security and compliance requirements.
Purpose-built platforms also introduce tradeoffs. They require a licensing investment and may involve implementation, migration, training, and professional-services costs. Customers may face execution limits, integration constraints, or dependence on the vendor’s product roadmap.
Support for Dynamics 365 can also vary considerably between products. Some focus on a specific application, while others can test processes that cross multiple Dynamics 365 applications and connected web systems.
When evaluating these platforms, teams should consider ease of use, maintenance effort, test-data management, reporting, cross-application coverage, security, integration with existing release processes, and total cost. They should also understand what will be required to migrate their current RSAT tests and what internal skills will still be needed afterward.
The correct comparison is not simply a commercial subscription versus a free open-source license. It is the total cost, effort, flexibility, and risk associated with operating each approach over time.
AI-Agent Testing
“Let’s build agents to do our testing.”
On its face, this seems like a compelling option. An AI agent can interpret instructions, navigate an application, adapt when something changes, and report what it finds. That sounds easier than maintaining traditional test automation.
The problem is that “AI testing” can describe several very different things.
Using AI to suggest test cases, identify coverage gaps, generate test data, recommend maintenance, or summarize failures is very different from allowing an agent to decide what actions to take and whether a test passed.
Regression testing requires a known process, a defined expected result, and a repeatable way to compare the two. If the same test is run against the same application state, teams need confidence that it will follow the same logic and evaluate the outcome against the same standard.
In another blog post, we discussed the problems that arise when critical test results depend on probabilistic output. AI models can produce different responses to the same input, and their behavior can change as models, prompts, and surrounding context change.
That variability may be acceptable when AI is recommending what to test. It becomes much more consequential when the agent is the final authority deciding whether a purchase order posted correctly, inventory moved to the right location, or a financial transaction produced the expected result.
A false failure wastes time. A false pass can allow a serious business problem to move into production.
There are also practical considerations. An agent executing tests may require access to application credentials, business data, and multiple connected systems. Teams need to understand what information is sent to the model, how credentials are protected, what permissions the agent receives, and whether every action and decision can be reviewed afterward.
Cost can also be difficult to predict. Agent-based execution may involve repeated model calls, screenshots, application context, retries, and long-running workflows. Token costs may be small during a pilot but can grow as test volume, execution frequency, and process complexity increase. The model cost is also only one part of the total expense. Teams still need execution infrastructure, test management, security controls, monitoring, and people to investigate uncertain results.
None of this means AI has no place in testing. AI can make test creation faster, help teams identify missing scenarios, assist with maintenance, analyze failures, and reduce the time required to understand results.
The important distinction is where AI is used. It can assist the testing process while deterministic steps and explicit assertions remain the source of truth for execution and pass or fail results.
AI can make a testing program more productive. It should not be the only authority deciding whether a critical business process worked.
What’s the Right Choice?
There is no single right answer for every team. The decision should account for total cost, internal skills, maintenance, security, and the reliability of the results.
Open-source tools trade licensing fees for engineering time, infrastructure, and ongoing maintenance. Purpose-built platforms require a commercial investment but can reduce that technical burden and make testing accessible to more of the organization. AI can improve test creation, maintenance, and analysis, but it should not be the sole authority determining whether a critical business process passed or failed.
Regardless of the approach, the investment should produce a measurable return. That return may come from reducing manual effort, shortening test cycles, expanding coverage, finding defects earlier, or lowering the risk of disruption after an update. The least expensive tool does not necessarily deliver the best ROI.
Before choosing, ask what the approach will cost, what measurable value it will produce, and who will build it, secure it, maintain it, and stand behind the results.
How Horizon Can Help
by is purpose-built to manage testing across D365 F/SCM, the broader Dynamics 365 suite, and connected web applications.
Point-and-click authoring makes testing accessible to business users, while advanced test-data and execution capabilities give technical teams the flexibility, security, and control required for enterprise testing.
Get Ahead of the May 2027 Deadline
Migrating from RSAT does not have to become a scramble. Our free RSAT migration assessment will help you evaluate your current coverage, identify gaps, and build a practical path forward.