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

# Migrate Lab

![Migrate Lab](https://1807546539-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhgHCHWL3861o2DBW53aA%2Fuploads%2FPjyWX66TtwlAyftR3go9%2Fve20261112v5-migrate-lab.png?alt=media)

## Goal

Upload a ZIP that contains a **`.unl`** topology file (and optional startup configs) from another lab platform, then create a VEX-NX lab.

## Why Migrate Lab exists

Many people already built labs elsewhere. Migrate saves redrawing every link. It is the bridge from "old tool export" to "VEX-NX lab".

**Why disks are separate:** UNL ZIPs usually describe **what** is connected, not multi-GB vendor images. You import images once under **Images -> Import**, then map them during the Migrate preview.

## Wrong button?

| Your ZIP                                                 | Use instead                           |
| -------------------------------------------------------- | ------------------------------------- |
| Contains `.unl` from another emulator                    | **Migrate Lab** (this page)           |
| Named like `something-vex-nx-lab.zip` from VEX-NX Export | [Import Lab](/labs/import-lab.md)     |
| Only running-config text                                 | [Generate Lab](/labs/generate-lab.md) |

## GUI tutorial

### Step 1 - Open Migrate Lab

![Migrate Lab](https://1807546539-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FhgHCHWL3861o2DBW53aA%2Fuploads%2FPjyWX66TtwlAyftR3go9%2Fve20261112v5-migrate-lab.png?alt=media)

1. Labs -> **Migrate Lab**
2. Confirm the upload / preview UI

|                  |                               |
| ---------------- | ----------------------------- |
| **What you see** | Migrate Lab dialog            |
| **Expected**     | ZIP picker and Preview import |

### Step 2 - Preview and map templates

1. Choose the `.unl` bundle ZIP
2. Click **Preview import**
3. Fix Checks (errors block create)
4. Map each node to a **template** and **image**
5. **Create lab** then open [Design mode](/labs/design-mode.md)

## Prepare your bundle

1. Save or export your lab as a `.unl` topology file
2. Optional: add startups under `configs/` (example: `configs/R1.txt`)
3. Import appliance disks via **Images -> Import** (the ZIP does not include disk images)
4. Zip the files and keep the ZIP ready

## Recipe: five-router UNL study lab

1. Labs -> **Migrate Lab**
2. Lab name: `ccnp-ospf-study`
3. Choose the bundle ZIP
4. Optional: enable **Remap interface names in startup configs to match VEX-NX templates**
5. **Preview import**
6. Read **Checks** - errors block create; warnings are advisory
7. For each node: pick **template** and **image** (or "No image - pick later")
8. Review links -> **Create lab**

## Expected result

* Same node names and links as the UNL (as far as the importer could map them)
* Configs attached when remap worked
* Lab opens in Design for final cleanup

## If it fails

* Errors in Checks -> fix template/image choices or missing mappings, then preview again
* Start fails later with missing disk -> finish Images Import and bind Library images
* Preview rejects the ZIP -> confirm a `.unl` is inside; otherwise try Import Lab or Generate Lab

## Related

* Import images
* [Bulk folder import](/images/bulk-folder-import.md)
* [Design mode](/labs/design-mode.md)


---

# 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://docs.vex-nx.com/labs/migrate-lab.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.