Direct answer
No. Historical test runs cannot be reassigned to new test case IDs during a cross-project migration, and requirement traceability does not survive a UI bulk copy or a standard API copy without manual remapping. The UI bulk copy does not have a published hard limit, but it is subject to browser session and server processing timeouts that make suites above ~1,000 test cases unreliable.
Confirmed facts
- Test Run association is immutable. In qTest a Test Run stores the testCaseId it was created against. The REST API treats the link to the Test Case as read-only after creation. A PUT/PATCH to a Test Run cannot change its testCaseId to a new ID.
- Cross-project copy creates new entities. Both the UI bulk copy and an API create operation in the target project generate new Test Case IDs. New IDs inherently sever the direct link to historical runs and to existing Requirement links that reference the source IDs.
- Requirement traceability is ID-based. A Requirement → Test Case link points to a specific Test Case ID in a specific Project. Copying a Test Case to another project creates a new ID, so the original Requirement link remains in the source project and is not automatically recreated in the target.
Likely explanation, not confirmed in public docs
- UI bulk copy performance. There is no published official threshold for "1,000 test cases". The practical failure mode is browser session timeout and server-side job processing limits. Large selections often result in partial completion, stalled jobs, or timeout errors, which is why teams report issues on larger suites.
- API scripting does not bypass immutability. Scripting gives granular control over custom field mapping and naming, but it cannot reassign existing Test Runs. It can only create new Test Cases and new future Runs in the target project.
Minimal steps for a small suite when history must be preserved
- Accept history stays in source. Keep the source project as the historical record. Do not attempt to move runs.
- Build an ID mapping table. Export source Test Cases with source Test Case ID, name, folder path, custom fields, and Requirement links. After creating them in target, record target Test Case ID.
- Create Test Cases in target via REST API with custom field mapping. Use the mapping table to preserve naming and metadata.
- Recreate requirement traceability in target. In the target project, recreate or map Requirements and create new Requirement → Test Case links using the target IDs. This is manual or scripted via the Requirements API.
- Document the mapping for reporting. Link reports to both projects or maintain a reference table for audit.
Uncertainty note: behavior can vary by qTest edition and version. Cloud vs Professional and API version affect available endpoints for Test Cases, Requirements, and Runs. Verification is required before running at scale.
One diagnostic detail that changes the recommendation
Are source and target in the same qTest instance and is an intra-instance move within the same project allowed? If the move can be done within the same project or via a supported move operation that preserves IDs, history and traceability are preserved. If it is a true cross-project or cross-instance migration, IDs will change and history cannot be transferred.
qtest