> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/migrate-to-contextqa/mabl-to-contextqa.md).

# Migrate from mabl

Export representative mabl browser tests, reconcile unsupported steps and artifacts, migrate the reviewed code or intent to ContextQA, and verify parity.

## Quick answer

Use mabl’s current CLI export as an intermediate artifact, not as proof of a lossless migration. Export representative user-authored browser tests to Playwright or Selenium IDE, record the mabl branch and environment used, reconcile mabl’s documented unsupported step types, and run the exported code independently. Then analyze the reviewed Playwright output with ContextQA’s documented repository workflow—or rebuild from a behavior packet—before comparing normal, seeded-failure, data, and evidence behavior in parallel.

## Understand the supported boundary

mabl’s official CLI documentation currently describes exports for user-authored browser tests in Playwright TypeScript, Selenium IDE, JSON, and CSV formats. It also lists step types that are not exported to Playwright or Selenium and says mabl-generated tests are excluded. See [Exporting tests from the mabl CLI](https://help.mabl.com/hc/en-us/articles/19084077703444-Exporting-tests-from-the-CLI) and verify the page against your mabl version before running the migration.

This ContextQA guide does not claim a direct mabl importer. The recommended path is:

```mermaid
flowchart LR
    A[mabl source test] --> B[mabl CLI export]
    B --> C[Export reconciliation]
    C --> D[Independent Playwright run]
    D --> E[ContextQA analysis or intent rebuild]
    E --> F[ContextQA pilot run]
    F --> G[Parallel acceptance and cutover]
```

{% hint style="warning" %}
The intermediate export can lose behavior before ContextQA processes it. Keep the original mabl test, branch, plan, environment, and run evidence authoritative until the ContextQA behavior passes review.
{% endhint %}

## Phase 1: Freeze the mabl source

Record:

```
mabl workspace/application:
mabl branch:
Environment and environment ID:
Application build/revision:
Plans and labels in scope:
Selected user-authored test IDs:
Generated tests in scope:
DataTables/data sources:
Credentials and integrations:
Baseline run IDs/artifacts:
mabl CLI version:
Migration owner:
```

Use immutable test and build references where available. Preserve a source run for every representative test.

## Phase 2: Inventory behavior before export

| mabl test ID | Business behavior | Assertions | Branch/environment | Data | Special steps | Last run | Owner |
| ------------ | ----------------- | ---------- | ------------------ | ---- | ------------- | -------- | ----- |
|              |                   |            |                    |      |               |          |       |

Inventory reusable flows, variables, DataTables, JavaScript, API steps, cookies, file operations, accessibility checks, email/PDF/MFA behavior, downloads, conditional logic, and plan-level configuration.

### Pre-classify documented export gaps

The current mabl documentation lists these step types as unsupported in Playwright or Selenium test exports:

* select steps;
* drag and drop;
* JavaScript snippets;
* API steps;
* cookie interactions;
* file uploads;
* download assertions;
* accessibility checks;
* MFA authenticator steps;
* email testing; and
* PDF testing.

It also says Selenium exports do not support conditional steps and that mabl-generated visit-home, link-crawler, and visual-smoke tests are not exported.

Treat this list as a starting point, then compare with the current official page and your export result. Product export behavior can change.

| Source feature | Tests affected | Exported?                    | Migration treatment                 | Owner |
| -------------- | -------------- | ---------------------------- | ----------------------------------- | ----- |
|                |                | Yes / Partial / No / Unknown | Rebuild / Retain / Replace / Retire |       |

## Phase 3: Export a representative test

Install and authenticate the mabl CLI using mabl’s official instructions and your organization’s approved credential process. Do not paste access tokens into a shell history, GitBook page, or migration artifact.

For a Playwright export, the official command pattern is:

```bash
mabl tests export <test-id> \
  --format playwright \
  --environment-id <environment-id> \
  --file <safe-output-path>
```

Add the documented mabl-branch option when the source test is not on the default branch. Run `mabl tests export --help` and the current official documentation before executing; do not infer option behavior from this example alone.

Use one output directory per source revision and do not overwrite earlier evidence.

## Phase 4: Reconcile source and export

| Check                  | Source mabl | Exported Playwright | Result      |
| ---------------------- | ----------- | ------------------- | ----------- |
| Test identity/branch   |             |                     | Match / Gap |
| Ordered actions        |             |                     |             |
| Positive assertions    |             |                     |             |
| Negative assertions    |             |                     |             |
| Conditional behavior   |             |                     |             |
| Variables and data     |             |                     |             |
| Reusable flows         |             |                     |             |
| Environment/base URL   |             |                     |             |
| Authentication/session |             |                     |             |
| Setup/cleanup          |             |                     |             |
| Special step types     |             |                     |             |
| Browser configuration  |             |                     |             |

If a required behavior is absent, do not silently patch the generated file and forget the source gap. Add a migration decision linked to the behavior packet.

## Phase 5: Run the export independently

In a clean, disposable environment:

1. Review the generated code and package requirements.
2. Install dependencies through the approved package process.
3. Supply only documented, nonproduction configuration and secrets.
4. Run the exported test against the same application build used for the mabl baseline.
5. Capture its result, failure diagnostics, browser, and environment.
6. Introduce a controlled application failure and confirm the export fails for the expected reason.

If the export does not run or loses a critical assertion, choose manual reconstruction or retain the test in mabl. Do not send a broken intermediate artifact into bulk migration.

## Phase 6: Prepare the ContextQA behavior packet

```
Behavior ID:
mabl test ID, branch, and environment:
mabl baseline run:
Export file and commit:
Export limitations affecting this test:
Preconditions and role:
Actions:
Required positive/negative/persisted assertions:
Data setup/reset:
Browser/device/network:
ContextQA destination:
Retained mabl behavior:
Reviewer:
```

For an accepted Playwright export, follow [Playwright-to-ContextQA migration](/migrate-to-contextqa/playwright-to-contextqa.md). Analyze and dry-run the repository before creating cases. For an export with material gaps, reconstruct the behavior directly through documented ContextQA authoring or requirement-import workflows.

## Phase 7: Map mabl concepts to ContextQA ownership

| mabl source                 | ContextQA destination                                                    | Required review                               |
| --------------------------- | ------------------------------------------------------------------------ | --------------------------------------------- |
| Browser test steps          | Natural-language ContextQA test steps                                    | Preserve intent and order                     |
| Assertions                  | UI/API/custom verification                                               | Preserve exact protected outcome              |
| Environment                 | ContextQA environment                                                    | Confirm same application build                |
| DataTable/variables         | Test data profile/environment variable                                   | Scope, isolation, reset, and secret handling  |
| Reusable flow               | Reviewed reusable design or expanded behavior                            | Dependencies and change ownership             |
| Plan                        | Purpose-based suite/test plan                                            | Browser/device, schedule, retry, and evidence |
| JavaScript/API/special step | Verified ContextQA step, manual reconstruction, or retained mabl control | Feasibility and security review               |
| Cloud artifacts             | ContextQA result/evidence plus retained source artifact                  | Access and retention parity                   |

## Phase 8: Preserve source evidence

mabl documents test-run artifact exports that can include screenshots, console logs, DOM snapshots, HAR files, traces, and other artifact types depending on browser and run. Use the current [mabl artifact export guidance](https://help.mabl.com/hc/en-us/articles/17781700176532-Exporting-test-run-artifacts) for your source evidence package.

Record availability rather than assuming every artifact exists for every browser.

| Artifact                 | mabl source run | ContextQA run | Required? | Access/retention gap |
| ------------------------ | --------------- | ------------- | --------- | -------------------- |
| Screenshots              |                 |               |           |                      |
| Console logs             |                 |               |           |                      |
| DOM snapshot             |                 |               |           |                      |
| HAR/network log          |                 |               |           |                      |
| Trace                    |                 |               |           |                      |
| Resolved-variable record |                 |               |           |                      |
| CI/release reference     |                 |               |           |                      |

Protect exported variables and artifacts as potentially sensitive. Review before attaching them to a ticket or migration repository.

## Phase 9: Compare in parallel

| Build | Behavior | mabl result | Export result | ContextQA result | Expected | Gap classification                           | Owner |
| ----- | -------- | ----------- | ------------- | ---------------- | -------- | -------------------------------------------- | ----- |
|       |          |             |               |                  |          | Export / Test / Data / Environment / Unknown |       |

Run normal and seeded-failure cases. Include one test affected by a documented export limitation, even if the decision is to retain it in mabl.

## Phase 10: Cut over by disposition

| Source test | Export result | ContextQA result | Final disposition                                | Authoritative system | Rollback trigger |
| ----------- | ------------- | ---------------- | ------------------------------------------------ | -------------------- | ---------------- |
|             |               |                  | Migrate / Retain / Replace / Retire / Unresolved |                      |                  |

Do not delete mabl tests or revoke credentials as part of content implementation. Perform operational cutover through a separate reviewed change after the overlap window.

## mabl migration checklist

* [ ] Workspace/application, mabl branch, environment, CLI version, test IDs, and baseline runs are recorded.
* [ ] User-authored and mabl-generated tests are separated.
* [ ] Current official export formats and limitations were reviewed.
* [ ] Every unsupported/special step has an owner and treatment.
* [ ] Representative tests were exported without overwriting prior evidence.
* [ ] Source-to-export steps, assertions, data, and setup reconcile.
* [ ] Exported Playwright runs in a clean environment.
* [ ] A seeded defect fails in the export for the intended reason.
* [ ] ContextQA analysis/dry run uses only the reviewed intermediate repository.
* [ ] ContextQA behavior and evidence pass parallel acceptance.
* [ ] Sensitive variables/artifacts are protected.
* [ ] Retained mabl tests, source of truth, overlap, and rollback are explicit.

## Common questions

<details>

<summary>Can ContextQA import a mabl test directly?</summary>

No direct mabl importer is documented here. Use a reviewed mabl Playwright export as an intermediate source or reconstruct the behavior through supported ContextQA inputs.

</details>

<details>

<summary>Does a successful mabl Playwright export preserve every step?</summary>

No. mabl publishes a list of unsupported step types and excludes mabl-generated tests. Reconcile the exact source test and current documentation before migration.

</details>

<details>

<summary>Should we choose the Selenium IDE export instead?</summary>

Use the path your team can execute and review reliably, but note that mabl documents additional conditional-step limitations for Selenium export. For ContextQA repository analysis, the reviewed Playwright route is generally easier to preserve as code, but it still requires acceptance testing.

</details>

## Related documentation

* [Migration overview](/migrate-to-contextqa/migration.md)
* [Migration planning checklist](/migrate-to-contextqa/planning-checklist.md)
* [Playwright migration](/migrate-to-contextqa/playwright-to-contextqa.md)
* [MCP-assisted suite migration](/migrate-to-contextqa/migrating-existing-tests.md)
* [Clean-environment portability test](/migrate-to-contextqa/migrating-existing-tests.md#run-a-clean-environment-portability-test)

{% hint style="info" %}
**Want to test a mabl migration using one representative export?** [**Book a migration review →**](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=mabl_migration) — Bring the source test, current export, and its documented gap list so the pilot starts with an honest boundary.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/migrate-to-contextqa/mabl-to-contextqa.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.