The Migration Their Team Now Owns

A top-three management consultancy was facing a 12-month manual migration of the analytics engine behind its mining advisory practice, and could not afford to take the platform offline to do it.

The firm serves mining companies worldwide with analytics, benchmarking, and strategic guidance. Its analytics engine processes production data across hundreds of mines and commodities. The platform had been built on SQL Server and had grown over the years into 1,700 stored procedures and 800 C# calculations, some of them running for six hours at a time.

The runtime cost was the visible problem. The bigger problem was where the platform sat in the firm's roadmap.

Modern analytics workloads needed Microsoft Fabric. Data lineage on the SQL Server platform was opaque, which made it hard for consultants to trace insights back to source. Every new capability the business wanted to add ran into the same wall: the foundation had been built for a different era. Accurate work. Reliable work. But not the foundation the next ten years of mining advisory needed to sit on.

A manual migration of 1,700 stored procedures and 800 calculations was estimated at over 12 months. The firm did not have a year to spare on a migration, and could not pull the platform offline to do it. Two engineering teams looking at the same problem reached the same conclusion: the math did not work without help.

Tecknoworks built an AI-assisted migration workflow with one goal beyond speed. The client's team had to come out of the engagement owning the methodology so it could run the next migration without us.

The workflow split the work into a clean separation of concerns. AI handled the mechanical conversion of stored procedures and calculations from the SQL Server dialect to Microsoft Fabric. The client's engineers analyzed the AI output, validated correctness against production data, and optimized the converted procedures for the new platform. Tecknoworks engineers paired with the client's team on the early procedures so the methodology transferred directly. By the back half of the engagement, the client's engineers were running the workflow on their own and Tecknoworks was acting as the review layer.

This was a production migration, not a pilot. The platform stayed live throughout. New stored procedures landed on Microsoft Fabric while older ones were still running on SQL Server. Cutover happened procedure by procedure as the client's team validated each one against production data.

AI is an effective accelerant for the mechanical part of a migration. It is not a substitute for the production engineering decisions that decide whether the migrated platform will hold. Tecknoworks owned those decisions: which procedures migrated first, how the data validation gate worked, how the live platform absorbed each cutover, what the rollback path looked like for each batch. The result was a workflow the client's team could re-apply. Not a black-box service. A methodology, transferred.

Before this engagement, the firm's engineering team treated platform migrations as multi-year programs that required outside specialist help. The size of the SQL Server estate (1,700 procedures, 800 calculations) was the whole reason the migration had been deferred for so long.

After it, the same team owns an AI-assisted migration methodology that compresses platform migrations from years to months. The next time a part of the analytics estate needs to move, they will not need an external lift. They have the workflow, the validation gates, the cutover playbook, and the engineering judgment to run it.

The firm bought a migration. It came out with a capability.