You've run the migration and you're looking at the result, wondering where a particular thing went. This page answers that.
The short version
In Azure Test Plans | In TestCollab |
Test plan | A test plan named [Azure TP] Your Plan Name |
Test suite : static, requirement-based or query-based | A suite |
Test case | A test case |
Steps (action + expected result) | Steps (action + expected result) |
Shared steps | Written out in full, inside every case that used them |
Tags | Tags |
Priority | Priority (see below) |
State, area path, work item ID and type, linked work items, parameters | Custom fields |
Things that deliberately look different
1. A test case used by several plans is stored once
In Azure the same test case often appears in several plans and suites. TestCollab keeps a single copy, files it under one folder, and links it to every test plan it belonged to. You're not maintaining four near-identical copies.
2. Slashes in suite names become dashes
A suite called Login / Logout would arrive as a folder named Login - Logout.
How priority translates
Azure rates test cases 1 to 4. TestCollab uses three levels, so:
Azure | TestCollab |
1 | High |
2 or 3 | Normal |
4 | Low |
Azure sets 2 by default, so most cases arrive as Normal. Only cases you deliberately marked as 1 become High, otherwise every untouched case would arrive looking urgent.
The custom fields you'll see
Some Azure details have no natural home in TestCollab, so the migration creates fields for them the first time it runs. You'll find them under Settings → Custom Fields, and filled in on each imported test case:
Azure ID · Azure Work Item Type · Azure State · Azure Area Path · Azure Priority · Azure Tags · Azure Linked Work Items · Azure Parameters
Azure ID is the handiest of the set, it's the original work item number, so you can always trace a test case back to where it came from. Azure Parameters holds the shared parameter names and values a case referenced, saved as text.
Who owns everything afterwards
The person you chose as default assignee in the wizard is assigned to every imported test plan and to the test cases inside those plans, and gets one task per plan. Nothing arrives ownerless.
Test cases that came across outside any test plan, if you ticked that option, sit at the top level of your repository with no plan and no assignment. They're yours to file.
What stays in Azure
Being upfront about this saves a support ticket later. The migration does not bring across:
Test runs and results history. Execution history stays in Azure.
Attachments, whether attached to a test case or to an individual step.
Images embedded in descriptions. The text arrives; the pictures don't.
Azure user accounts. Nobody's Azure identity is matched to a TestCollab user, which is why you choose one assignee for everything.
Test configurations.
Any other Azure custom fields beyond the ones listed above.
The formatting inside your steps: bold, lists, links; comes through and stays readable.
A note on running it again
This is a one-time move. You can't migrate the same Azure project into the same TestCollab project a second time, and TestCollab blocks the attempt rather than quietly doubling your library.
You can migrate the same Azure project into a different TestCollab project as often as you like. If a run didn't come out the way you wanted, that's the route: start with a fresh project rather than trying to patch the old one.