Microsoft Playwright Testing service was retired. The cleanest migration might be off the cloud lifecycle entirely

Microsoft Playwright Testing (MPT) Preview was retired on March 8, 2026. The retirement notice went out in September 2025 with a six month runway. Existing MPT workspaces stopped accepting new runs on that date. The successor is Azure App Testing, which bundles a Playwright Workspace together with Azure Load Testing into a single unified service under a new SKU. Technically the capability is not gone: it was rebranded, merged, and re-billed. Practically, if you had automation pointed at the old MPT service endpoint and the @azure/microsoft-playwright-testing package, you had to recreate a workspace, install @azure/create-playwright, update config, and re-run your CI to validate. So the answer depends on what you mean by gone. The SDK, the SKU, the endpoint, and the portal all changed. The underlying idea of running Playwright tests in Microsoft-hosted Linux and Windows browsers is still there, under a new name.

Billing is per second of total browser time across parallel workers, rounded up and summed into test minutes. The example Microsoft publishes is 50 tests at 12 seconds each, which comes out to 10 minutes billed. That sounds cheap until you multiply by your real suite. A 300 test suite at 20 seconds average across 10 parallel workers burns 100 minutes per full run, and most teams run 5 to 30 full suites a day between pre-merge checks, cron-scheduled smoke tests, and release gates. At production scale you are buying a four-digit minute bucket every month. The second bite is parallelism: MPT caps at 50 simultaneous browsers, and you pay linearly for each one. A self-hosted runner on a single 16 core box can saturate well past that with no per-minute meter, and a local dev loop costs nothing at all. The point of the old MPT pricing page was that test minutes scale smoothly. That is true. It also scales smoothly upward.

One: create a new Azure App Testing resource in the portal and inside it provision a Playwright Workspace. Two: replace the old @azure/microsoft-playwright-testing npm dependency with @azure/create-playwright. Three: rewrite the service endpoint URL and the regional fields in your playwright.service.config.ts, because the new workspace has a new endpoint shape. Four: re-issue CI credentials, because the old MPT access tokens do not authenticate against the new service. Five: re-onboard any stored test artifacts you cared about; the dashboard URLs changed. Six: validate by running a full suite and checking that the unified dashboard shows the results. Most teams report this as a half day of work if they have one project and a full week if they have five, because each pipeline needs its own config and credential update. If your tests were authored inside a vendor UI rather than as Playwright code on your disk, this migration would be much harder. MPT at least wrote plain .spec.ts files in your repo, so the code survives the platform change. That is not true for every testing service on the market.

Because the retirement itself is a signal. Microsoft shipped MPT as a preview in September 2023, left it in preview for roughly two years, then rolled it into a different SKU with a three week migration window at the tail end. Product lifecycles in the big cloud providers are not the same shape as product lifecycles in your repo. If you let your test infrastructure become dependent on a service that can be rebranded, deprecated, or re-priced on a timeline you do not control, the next sunset becomes your problem too. The observation is not that Azure App Testing is bad. It is probably a better product. The observation is that anything that can be retired, will eventually be retired. For a subset of teams, the right response to an MPT retirement is not to port to Azure App Testing. It is to stop paying a cloud service for something as fundamental as end-to-end testing.

Three files. /tmp/assrt/scenario.md is the plan, a Markdown file containing #Case blocks with the steps the runner will execute. /tmp/assrt/scenario.json is the metadata: a UUID, the name, the URL, and a timestamp. /tmp/assrt/results/latest.json is the most recent run's structured output. Those paths are defined as constants at /Users/matthewdi/assrt-mcp/src/core/scenario-files.ts lines 16-20, not abstracted behind a service layer. When a forced migration hits, say because you are moving off your laptop, changing cloud vendors, or archiving a project, the migration is cp -r /tmp/assrt /new/location. No workspace to provision, no SKU to pick, no credential to re-issue. If Assrt itself disappeared tomorrow, you would still have a Markdown file that a human can read and that a scripting language can parse. That is the upper bound on how much of your work a tool sunset can take from you.

Same Playwright. Specifically @playwright/mcp, the official Playwright Model Context Protocol server from the Playwright team. The Assrt runner spawns it as a child process, drives it to open real Chromium (or WebKit, or Firefox), and sends it navigate, click, type, screenshot, and snapshot commands. There is no custom browser fork, no proprietary driver, no YAML-to-Playwright translator in the hot path. The difference from MPT is not the execution engine: it is what the test artifact looks like (intent Markdown rather than generated TypeScript) and where the browser runs (on your local machine or your own CI runner rather than in a Microsoft data center). If your existing Playwright tests depend on @playwright/test assertions or custom fixtures, Assrt does not replace those directly; what Assrt replaces is the cloud orchestration layer and the test authoring model.

Yes, and that was its best-case value prop. If your suite is 2000 cases and you want the full run in under 10 minutes, spraying them across 50 cloud browsers is faster than running them on one laptop. But a couple of things about that. First, the parallelism is a property of the Playwright test runner, not a proprietary MPT feature; you can do the same thing on your own infra with projects in playwright.config.ts and a handful of big machines. Second, most teams never actually approach 2000 cases, because most teams do not maintain 2000 cases; what they actually have is 20 high-signal smoke tests plus some higher-volume unit tests that do not need browsers. Third, for intent-based tests in the Assrt model, one Chromium can handle a lot of cases sequentially because each case is 3 to 5 actions, so a 20 case suite finishes in a minute or two without any parallelism at all. The 50-browser number is impressive but not always the constraint you thought it was.

If you need CI green today and you already have Playwright .spec.ts files, the fastest unblock is to strip the MPT service config and run Playwright locally on your CI runner. In your playwright.config.ts, delete the connectOptions.wsEndpoint that pointed at the MPT endpoint. The same @playwright/test command will now use the installed browsers on the CI runner. GitHub Actions and Azure DevOps both have Playwright base images that pre-install the browsers, so you are looking at a 30 line diff and a slower but green run. Then you decide later whether to port to Azure App Testing, scale up your own runners, or re-author your tests in a more portable shape. The point is that being blocked on MPT's retirement does not have to mean being blocked on the whole re-platforming decision at once.

The orchestration layer is open. The assrt-mcp server (the MCP interface that Claude Code, Cursor, and other coding agents call), the web scenario UI, the runner, and the plan generator all live in public repos. The implementation depends on third-party libraries, of course: @modelcontextprotocol/sdk for the tool protocol, @playwright/mcp for the browser agent, and the Anthropic SDK for the LLM call that generates test cases. If you swap the Anthropic endpoint for a local proxy via ANTHROPIC_BASE_URL, no network egress leaves your machine during a test run. That is a different security posture from a cloud testing service that by definition sends your test state, URLs, and screenshots to a third-party data center. For teams with strict data policies, this is the decisive difference.

Yes, and many teams do this. Existing @playwright/test spec files keep working against your local runner or any cloud Playwright service. Assrt's intent-based #Case format is a different authoring model intended for a different kind of test: the high-level user-flow smoke test that you do not want to maintain locator strings for. Keep your unit-level Playwright specs for edge cases (specific data-testid assertions, network mocks, cookie tests), and let Assrt own the plain-English walkthroughs (new user signup, checkout, dashboard loads). That division is what most MPT users converge on when they migrate: keep the Playwright code that is genuinely theirs, move the churn-heavy user-flow tests to a format that does not rot every sprint.