Migration Overview
Choose a safe ContextQA migration path for Playwright, Selenium, Tricentis Tosca, or mabl while preserving assertions, data, evidence, and rollback.
Quick answer
A safe migration preserves the business behavior, assertions, test data, environment assumptions, and evidence needed for a release decision—not just the old tool’s step count. ContextQA can analyze supported code repositories through its documented MCP migration workflow. For proprietary or unsupported source formats, use a staged conversion: inventory the source, extract human-readable intent and evidence, rebuild a representative slice, compare results in parallel, and migrate only after acceptance and rollback gates pass.
Choose your source
Playwright repository
Helpers, fixtures, custom code, projects, and assertions require review even when repository analysis succeeds
Selenium repository
Page objects, waits, framework hooks, and external libraries may not map one-to-one
Tricentis Tosca
No direct Tosca-subset importer is documented here; preserve business intent and rebuild through a controlled conversion
mabl
mabl can export some browser tests to Playwright, Selenium IDE, JSON, or CSV, but its documented export has unsupported step types
Mixed or another framework
Classify each source asset before choosing direct analysis, intermediate export, or manual reconstruction
Keeping execution in your own repository? Use the Cypress-to-Playwright migration guide to preserve assertions, request behavior, authentication, and saved state. That guide starts with a framework-to-framework example and then explains an optional ContextQA evaluation.
The three migration paths
Direct repository analysis
Use the MCP-assisted migration workflow for a supported Selenium, Cypress, Playwright, or Jest repository. Analyze first, run a dry run, inspect skipped tests, then migrate a small set.
“Supported analysis” does not mean lossless conversion. Review generated steps and required assertions against the source.
Intermediate export
Some platforms export browser tests into code or a structured file. Treat the export as an input candidate:
Read the source vendor’s current export limitations.
Compare exported and source test inventories.
Identify unsupported steps, data, reusable components, and assertions.
Run the export independently when possible.
Analyze or reconstruct only after the intermediate artifact passes review.
An intermediate export can lose semantics before ContextQA ever sees it. Preserve the source record until the migrated test passes its acceptance checks.
Intent-led reconstruction
Use this path for proprietary, binary, heavily model-based, or unsupported source assets. Extract:
requirement or business-risk link;
preconditions and user role;
ordered actions;
positive, negative, and persisted-state assertions;
data and environment dependencies;
current execution evidence; and
cleanup or rollback behavior.
Rebuild the smallest representative workflow first. Do not translate proprietary implementation details that no longer serve the business intent.
Preserve the migration unit
The migration unit is not “one old test equals one new test.” Use a behavior packet:
One source test may become several ContextQA cases when it contains unrelated behaviors. Several repetitive source tests may become one parameterized case with a reviewed data profile.
Use migration waves
0 — inventory
Suite map, dependencies, evidence, owners
Establish scope and find unknowns
1 — representative pilot
5–15 tests across easy, complex, negative, and data-heavy cases
Test the conversion method
2 — release-critical
Stable, high-value workflows
Prove parallel-run and gate behavior
3 — broader regression
Remaining supported tests
Scale with measured review capacity
4 — specialist/legacy
Rare, proprietary, or low-value cases
Rebuild, retain, replace with another control, or retire explicitly
Do not start with the easiest hundred tests and call the migration validated. Include at least one case that exposes fixtures, data, permissions, custom logic, and failure diagnostics.
Acceptance gates
Every wave should pass these gates:
Inventory
Every source test has a disposition and owner
Assertion integrity
Critical expected outcomes are reviewed in ContextQA
Failure fidelity
A reversible seeded defect fails for the intended reason
Environment parity
Build, data, identity, network, browser/device, and locale are recorded
Evidence
Reviewers can open the run and required artifacts
Operating fit
Creation, review, triage, and maintenance effort are measured
Parallel comparison
Source and candidate divergences are classified
Rollback
The source path remains runnable through the acceptance window
Portability
Export and residual dependencies are documented when required
Use the complete migration planning checklist to record these gates.
What not to carry forward automatically
sleeps or waits that only compensate for source-runner behavior;
selectors when the migrated step should express stable user intent;
retries that hide a deterministic defect;
duplicated tests with no distinct risk or environment;
credentials embedded in source code, spreadsheets, or exported files;
old execution history without its build and environment context; and
vendor-specific recovery logic that weakens an assertion.
Retiring an obsolete test is acceptable when the decision and rationale are recorded. Silent omission is not.
Definition of done
A migration is complete when:
the source inventory reconciles to migrated, retained, replaced, or retired dispositions;
critical requirements map to reviewed ContextQA assertions;
representative normal and seeded-failure runs behave as expected;
test data, environment, browser/device, and credential ownership are documented;
the CI/release path distinguishes pass, fail, and unknown outcomes;
reviewers can reach the required evidence;
overlap results and unresolved divergences are signed off; and
rollback and exit/portability records are complete.
Related documentation
Last updated
Was this helpful?