TestRail Migration Guide: Move Your Team Safely to Tuskr

A TestRail migration involves moving your TestRail projects, test case structure, test steps, test case types, custom fields, users, roles, and permissions into Tuskr. This guide explains how to prepare your data, use Tuskr’s native TestRail migration option or CSV importer, validate the imported test cases, plan separately for attachments and historical execution data, and reconnect the tools your team uses after the move. Tuskr’s published TestRail migration scope covers projects, test cases, steps, types, custom fields, users, roles, and permissions.

The problem with any migration is that two systems rarely store every type of data in exactly the same way. If your team assumes that test cases, attachments, old results, users, permissions, and integrations will all move automatically, important gaps may only appear after TestRail has been switched off. The safer solution is to separate the migration into supported data, data that needs manual handling, and data that should remain in a historical archive—and validate each part before making Tuskr your main system.

Tuskr is a cloud-based test management platform designed around focused, practical workflows rather than trying to reproduce every feature of every legacy tool. It provides structured test cases, suites and sections, test runs, custom fields, role-based privileges, reports, automation-result imports, and integrations at published per-user prices. Tuskr does not provide test case versioning, so teams that depend heavily on full test case version history should consider that difference before migrating.

Why QA Teams Are Leaving Legacy Test Management Tools

Teams migrating from legacy test management tools are not always looking for the platform with the longest feature list. Many want a system that is easier to learn, requires less administration, has clear pricing, and supports the testing work they perform every day.

• A complicated interface that makes routine work slower
• Per-user costs that become difficult to manage as the team grows
• Too much setup for simple test case and test run workflows
• Manual and automated results being stored in different places
• Integrations that no longer match the team’s current development process
• A desire to keep test management separate from Jira while still creating and tracking Jira defects

This is why teams often search for an answer to: “We’re moving away from TestRail—what’s the easiest test management tool to migrate to?” The practical answer is a tool with a purpose-built TestRail migration path, a clear CSV fallback, and honest documentation about the data that requires separate handling.

Tuskr focuses on the needs of teams that want test case management, test execution, reporting, permissions, and automation-result imports without an unnecessarily complex interface. It is not intended to copy every TestRail capability. For example, Tuskr does not provide test case versioning. That narrower focus can make it a better fit for teams that prefer simple—not simplistic—test management.

Pre-Migration Checklist: What to Prepare Before You Leave TestRail

Complete these checks before exporting any data:

• Define what must move. Separate active test cases from old test runs, attachments, reports, closed projects, and other historical records.
• Record your current totals. Count projects, suites, sections, test cases, users, custom fields, active test runs, and attachments. You will use these numbers during validation.
• Preserve a source copy. Keep TestRail available or retain exports and backups until the migration has been validated and approved.
• Clean the repository. Archive or remove duplicate, obsolete, and incomplete test cases before exporting.
• Review custom fields. Record each field’s name, type, allowed values, and whether it is still needed.
• Review users and permissions. Identify inactive users and confirm which people need access to each Tuskr project.
• Choose a pilot project. Start with one representative project before moving the full repository.
• Plan for unsupported data. Decide how you will preserve attachments, historical run results, timestamps, comments, and defect links that are not included in Tuskr’s documented native migration scope.
• Set a cutover date. Avoid editing the same test cases in both systems after the final export.

Tuskr’s native TestRail migration is documented for projects, test cases, steps, types, custom fields, users, roles, and permissions. Test runs, complete execution history, and test case attachments are not listed in that migration scope, so they should be treated as separate workstreams.

Rebuilding Integrations and Automation

Rebuild each connection based on Tuskr’s current integration model rather than assuming every TestRail integration has a matching native Tuskr app.

1. Jira: Tuskr provides a native Jira integration using an API token for creating issues when tests fail. Tuskr also documents a Make-based Jira integration for more configurable workflows, including creating issues and marking a failed test as ready for retesting after the Jira issue is fixed.
2. GitHub: Tuskr’s documented GitHub workflow uses Make to create GitHub issues when tests fail.
3. Playwright and Cypress: These integrations use JUnit XML results and the Tuskr CLI. The CLI can run inside the CI/CD pipeline that already executes the automated tests.
4. Jenkins and other CI systems: Jenkins is not documented as a separate first-party connector. A Jenkins pipeline can execute the Tuskr CLI after generating JUnit XML results.
5. Webhooks and APIs: Use them when your workflow needs custom behavior not covered by a documented blueprint. API-call and webhook limits depend on the Tuskr plan.
6. Email notifications: Tuskr can send email notifications to followers when new test case comments are added. Review notification behavior during onboarding rather than assuming it matches TestRail exactly.

For teams searching for a TestRail Slack integration, Tuskr does not provide a traditional native Slack app. Tuskr’s current documented Slack integration uses Make and can send Slack messages when test cases fail. Teams that already post build notifications from Jenkins, GitHub Actions, or another CI/CD service may also continue routing notifications to Slack from that pipeline.

How to Import Test Cases from TestRail to Tuskr

If you are moving from TestRail to Tuskr, there are two ways to bring your test cases and project data into Tuskr:

1. Direct Migration from TestRail – Tuskr connects directly to your TestRail account and imports the data for you.
2. CSV Import – Export your test cases from TestRail as a CSV file, format the file according to Tuskr’s CSV template rules, and then import the file into Tuskr.

The direct migration method is usually easier when you want to move your TestRail project data without manually preparing a CSV file. The CSV method is useful when you want more control over the data before importing it.

Method 1: Direct Migration from TestRail

Tuskr provides a Migrate option that allows you to connect your TestRail account and import your data directly.

Step 1: Open the Migrate option

Log in to your Tuskr account and open the Migrate option.

Select TestRail as the source from which you want to migrate your data.

Tuskr will then ask you for your TestRail account details.

Step 2: Enter your TestRail credentials

Enter the following TestRail details:

• TestRail Domain – Your TestRail account domain.
• Email – The email address associated with your TestRail account.
• API Token – Your TestRail API token.

Make sure that the details are correct before continuing.

Tuskr uses these details to connect to your TestRail account and fetch the available data.

Step 3: Fetch your TestRail data

After entering your credentials, start the migration.

Tuskr connects to TestRail and fetches the available data from your account.

Once the data is fetched, you can continue with the migration process.

Step 4: Invite users

During migration, Tuskr may find users in your TestRail data who do not already exist in your Tuskr account.

You can choose to:

• Invite the users to Tuskr, or
• Skip the users if you do not want to invite them.

Review the users carefully before continuing.

If you invite a user, they can join your Tuskr account and continue working with the migrated project data.

Step 5: Select a project to import

Tuskr allows you to import projects one at a time.

Select the TestRail project that you want to migrate.

Review the project and start the import.

After the project is imported, you can return to the migration screen and import another project.

This gives you control over which TestRail projects you want to bring into Tuskr instead of importing everything at once.

Step 6: Verify the imported project

Once the migration is complete, open the imported project in Tuskr.

Check that the test cases and other migrated data are available as expected.

You can then continue working with the project in Tuskr.

Method 2: Import TestRail Test Cases Using CSV

The second method is to export your test cases from TestRail and import them into Tuskr using a CSV file.

This method is useful if you want to review or modify the test case data before importing it into Tuskr.

The process has three main parts:

TestRail → Export CSV → Format CSV → Import into Tuskr

Step 1: Export test cases from TestRail

Log in to TestRail and open the project containing the test cases you want to move.

Export the required test cases as a CSV file.

Save the exported file to your computer.

Step 2: Prepare the CSV file for Tuskr

The CSV exported from TestRail cannot simply be uploaded to Tuskr as-is.

Tuskr expects the CSV file to follow its own import format.

Open the exported CSV file and format the columns and values according to the Tuskr CSV import template rules.

Make sure that the required fields are mapped to the appropriate Tuskr fields.

For example, information such as the test case title, steps, expected results, priority, and other supported fields should be placed in the columns expected by the Tuskr import template.

Tip: Always use the latest Tuskr CSV import template/rules when preparing the file. This helps avoid errors during import.

Tuskr’s CSV importer requires a UTF-8 CSV file. It supports custom fields, multiline values, suites, sections, and structured test steps. Tuskr can also create suites and sections during import. A maximum of 1,000 test cases can be imported in one batch, so larger repositories must be split into multiple files.

Pro tips:

• Use clear column headers in the first row.
• Keep each test case’s suite and section names consistent.
• Remove empty and unused columns.
• Check dates, numbers, dropdown values, and user names before importing.
• Save the final file using UTF-8 encoding.
• Split files at suite or section boundaries when the export contains more than 1,000 test cases.
• Use +++ to separate steps and >>> to separate a step’s instruction from its expected result when using Tuskr’s alternate step format.

Step 3: Review the CSV file

Before importing the file, review the CSV carefully.

Check that:

• The column names match the Tuskr template.
• Required fields contain valid values.
• Test case information is in the correct columns.
• There are no unnecessary columns or incorrectly formatted values.
• The CSV contains the test cases you actually want to import.

This step is especially useful when you have a large number of test cases.

Step 4: Import the CSV into Tuskr

In Tuskr, open the project where you want to import the test cases.

Use the Import option and select the CSV import option.

Upload the CSV file you prepared.

Tuskr will process the file and import the test cases into the selected project.

Step 5: Verify the imported test cases

After the import finishes, open the relevant test cases in Tuskr.

Verify that the important information has been imported correctly, including the test case details and supported fields.

If something is not mapped correctly, update the CSV and perform the import again as needed.

Which Migration Method Should You Use?

Both methods allow you to move test case data from TestRail to Tuskr, but they work differently.

Use Direct Migration when

You want a simpler migration process and want Tuskr to fetch the data directly from TestRail.

You only need to provide your TestRail domain, email, and API token, handle the users found during migration, and then import your projects one by one.

Use CSV Import when

You want more control over the test case data.

For example, you may want to review the exported TestRail data, change the field mapping, remove unwanted data, or prepare the test cases before importing them into Tuskr.

Onboarding and Scaling Your QA Team

Start with the pilot group that validated the migration, then expand access in stages.

• Assign users the correct role in each project.
• Train testers on the Project, Test Cases, Test Runs, and My Work areas.
• Explain the suite and section naming rules.
• Document how custom fields and field sets should be used.
• Show testers how to enter results, comments, actual time, and defect information.
• Train leads to use the test run dashboard, progress bar, workload chart, and burndown-style progress view.
• Create standard test plans for regression, sprint, and release testing.
• Review reports and project-level results with stakeholders.
• Gather feedback before migrating the next project.

Tuskr’s My Work area shows active runs, assigned testing work, deadlines, and unread messages. Test run dashboards show progress and workload distribution, while test plans can group multiple runs for a release or testing cycle.

What Changes When You Move Off a Legacy Test Management Tool

When migrating from legacy test management tools to Tuskr, expect both improvements and trade-offs:

• Tuskr is cloud-based. Current Tuskr documentation does not offer an on-premise deployment option.
• The product is deliberately focused. The interface is designed for test cases, runs, reports, requirements, issues, and integrations without trying to reproduce every specialised enterprise feature.
• Tuskr does not provide test case versioning. Teams requiring full test case revision history should evaluate this limitation before switching.
• Manual and automated results can be viewed in the same platform. Automated results enter Tuskr through the CLI and JUnit XML workflow.
• Not every integration is native. Jira has a native option, while many tools—including GitHub and Slack—use Make. Automation frameworks use the Tuskr CLI.
• Tuskr supports detailed access control. Roles contain privileges and are assigned to users per project.
• Audit logs have a retention limit. Tuskr records important inserts, updates, and deletions, but audit records are automatically deleted after one year.
• Security controls are available. Tuskr documents SAML 2.0 SSO on select plans, two-factor authentication, role-based privileges, and security certifications.
• Reporting is built into the testing workflow. Tuskr supports visual and tabular reports, project result reporting, test run dashboards, and workload views.
• Pricing is published. Tuskr provides a free plan and annual Team, Business, and Enterprise plans with documented usage limits.

Frequently Asked Questions

Ready to Make the Switch from TestRail to Tuskr?

A successful TestRail migration is not about moving every file as quickly as possible. It is about understanding what Tuskr can migrate directly, preserving unsupported historical data, validating the result, and giving the team a clear cutover process.

Start with one pilot project. Use the native XML migration when you want to transfer the supported TestRail project, case, field, user, and permission data. Use CSV when you need selective migration or field cleanup. Keep TestRail or a reliable archive available for historical runs and attachments until stakeholders confirm that nothing important is missing.

Tuskr provides a focused test management experience with structured test cases, test runs, custom fields, reports, permissions, automation-result imports, and flexible integration options. For teams that value a simpler interface and transparent pricing—and do not require features such as test case versioning—it can provide a practical path away from TestRail.