Table of content
Organizations that have accumulated decades of test data all hit the same wall when they consider changing test management tools. It isn't a missing feature, and it isn't price. It's fear. Years of requirements, test history, and audit trails are locked inside the platform in place, and every team that considers a change has heard a migration horror story. ' We'd love to migrate, but we can't put our data at risk' has killed more migration projects than any functional gap ever has.
That's the problem SQALogic set out to solve. After months of development, we're proud to introduce a platform that makes migrating test data between OpenText ALM (formerly Micro Focus ALM / HP Quality Center) and Tricentis qTest simpler, faster, and safer than ever, and in both directions.
The neutral bridge between two major ecosystems
As a Platinum partner of OpenText and a Premium partner of Tricentis, SQALogic holds a unique position: the neutral bridge between two major test management ecosystems.
Test data migrations happen in both directions Tooling consolidation after an acquisition, enterprise-wide standardization, regulatory alignment, portfolio reorganization: our platform is designed to serve them all, without taking sides.
Whatever direction your project takes, the question that matters is the same: will your data arrive intact, and can you prove it?
A certified migration platform built to inspire confidence
SQALogic has built a certified migration platform designed to move test management data from one platform to the other.
The design goal was simple: it must never fail silently. Every write is verified as it happens: every entity, link, step, run, and attachment is accounted for, and the process ends with an automatically computed verdict. Either it proves data fidelity, or it states precisely what went wrong. An independent, read-only certification pass then re-derives the entire dataset and produces an audit-grade certificate.
This wasn't validated on a small demonstration dataset. Our reference migration moved a real 340,000-entity project, including 121,000 test runs, along with 591,000 design steps, 324,000 attachments, and 68,000 traceability links, end to end, in under a day. The resulting certificate confirmed more than one million verifications and zero content loss.
Building due diligence directly into the product
Migration projects usually fail at the due-diligence stage, so we built that process directly into the product. It rests on three elements:
1. A portfolio estimator:
Point it at a client's tooling estate and it produces a one-pager per project plus a portfolio summary, with timelines, durations, and a guaranteed contractual range calibrated against the actual recorded timings of certified real-world migrations. When a large account asks what its 40 projects would look like migrated, the answer is a document, not a lengthy discovery exercise.
2. A readiness audit:
A single read-only pass over a project archive, enforced by the code itself. Produces a clear GO / GO-WITH-NOTES / BLOCKED verdict the client's security team can review before any migration launches. It lays out every field mapping in advance, matches every user, states the identity-model decision and its consequences, and ties every quirk or risk to a concrete remedy.
3. An evidence pack.
At the end of every migration, each migrated entity is hyperlinked to its new location in the destination platform. The pack ships natively in Excel for the people who will actually open it, includes full attachment accounting, and closes with the fidelity certificate. Exactly what a regulated institution's governance function needs for its records.
What happens behind the scenes
The platform also handles the operational work consultants usually manage by hand: rate limiting tuned to each client environment, automatic extraction of oversized attachments and re-creation of their links to the client's shared storage, execution that can resume at any point right where it stopped rather than restarting from scratch, and idempotent provisioning of fields, users, and folder trees. None of this sits on a future roadmap. All of it worked in the reference migration, and that migration can be reproduced on demand.
That level of reliability comes from three decades spent deep inside test management platforms: proprietary archive formats and their version-specific quirks, the intricate relationships between reusable steps and call structures, and the gap between what a system's API reports and what its database actually means. We hit every one of those traps on our own test bench so our clients never have to.
The architecture was also designed from day one to accommodate new platforms, both as sources and as destinations. What never changes from one migration corridor to the next is the proof layer: every write verified, a computed verdict, an independent certificate.
How this differs from existing tools and service engagements
It's a fair question, and there are two honest distinctions to draw.
A different definition of 'success' :
A migration isn't successful when the data lands. It's successful when the client renews. Our model goes the full distance: training, adoption support, and delivery of the first releases on the new platform. A migrated client who never adopts their new tool eventually becomes a lost account (a story this industry has watched repeat far too often...). Provably extracting the data is only half the job; keeping the client is the other half. Migrations fail on the data side, and renewals fail on the adoption side. This platform is built to carry both.
A product guarantee, not a service engagement:
Import utilities and migration scripts, ours or anyone else's (including our own from two years ago), move data as best they can, billed by the hour. This platform delivers an automatically computed fidelity verdict and an independent certificate, which lets us offer a fixed timeline with a guaranteed range. The software absorbs the failure modes, not the consultant.
Proven in the field
This isn't a theoretical solution. A recent enterprise-scale full migration, completed in under three months with the tools available at the time, is exactly what inspired this platform. We encountered every situation where standard tools hit their limits against enterprise-scale data, and we engineered those failure modes out of the product.
We know what a migration done with everyday tools looks like. This platform is what we built the day we asked ourselves what a migration done right would look like.
Frequently asked questions
Which platforms are supported?
OpenText ALM (including earlier versions known as Micro Focus ALM and HP ALM / Quality Center) and Tricentis qTest, in both directions: ALM to qTest and qTest to ALM. The architecture is designed to accommodate new sources and destinations.
How long does a migration take?
Our reference migration moved 340,000 entities in under 24 hours. The portfolio estimator provides a per-project timeline with a guaranteed contractual range, calibrated against the actual recorded timings of certified real-world migrations.
How is data fidelity proven?
Every write is verified as it happens, then an independent read-only certification pass re-derives the full dataset and produces an audit-grade certificate. The client receives a complete evidence pack in Excel, with a hyperlink to every migrated entity.
What happens to oversized attachments?
They're detected, extracted automatically, and re-linked to the client's shared storage, with every file's disposition tracked in the evidence pack.