Global Insurer Migrates 2,800 Alteryx Workflows to Databricks, Cuts Licensing Costs by $5.2M

Executive Summary

A global insurance and reinsurance leader operating across 40 countries faced ballooning Alteryx Server and Designer licensing costs, brittle batch macro dependencies, and data pipeline throughput ceilings that limited their actuarial and risk modeling capabilities. Over 14 months, MigryX migrated all 2,800 Alteryx workflows — spanning .yxmd, .yxmc, and .yxzp package formats — to PySpark running natively on Databricks, backed by a Delta Lake storage layer. The engagement delivered over 700,000 lines of production-quality PySpark code, performance improvements of 3–7X on benchmark pipelines, and a projected $5.2 million in total cost savings over three years. The client decommissioned all Alteryx Server nodes within 60 days of final cutover.

Client Overview

The client is a multinational insurance and reinsurance group with operations spanning property & casualty, life, and specialty lines. Their data engineering function supports underwriting, actuarial reserving, claims processing, and regulatory reporting across multiple regulatory jurisdictions including Solvency II, NAIC, and Lloyd's market requirements. The organization had built a substantial Alteryx estate over eight years, starting as a business-analyst-friendly tool for ad hoc analytics and gradually expanding into a core data pipeline platform that was never designed to carry production-grade, enterprise workloads at scale.

By 2024, the Alteryx estate had grown to the point where licensing, infrastructure, and operational support consumed over $1.8 million annually. Workflows ran on a Windows-based Alteryx Server cluster that required specialized administrator knowledge and was increasingly difficult to integrate with the organization's cloud-first data strategy built on Azure Databricks and Azure Data Lake Storage Gen2.

Business Challenge

The decision to migrate was driven by a convergence of technical debt, cost pressure, and strategic platform direction. Key challenges identified during the MigryX discovery phase included:

• Escalating licensing costs: Alteryx Designer and Server licensing had increased by over 40% in three renewal cycles. With 220+ named Designer users and a multi-node Server cluster, the annual spend had become the second-largest line item in the data engineering budget.
• Batch macro complexity: Approximately 380 workflows used iterative or batch macros to loop over datasets or parameterize execution. These macros had no direct analog in standard ETL frameworks and required deep Alteryx-specific knowledge to maintain, creating single-threaded execution bottlenecks and knowledge concentration risk.
• In-DB connector fragility: Over 200 workflows used Alteryx In-DB tools to push computation down to Oracle, SQL Server, and Snowflake. These connectors had version-specific behavior differences and frequently broke during database driver updates.
• Scalability ceiling: Alteryx processes data row-by-row on a single worker node. Several actuarial batch jobs processing 50M+ row policy datasets required multi-hour execution windows that conflicted with daily reporting SLAs.
• Windows-only execution: All Alteryx Server nodes ran Windows Server 2019, incompatible with the organization's Linux-centric containerized infrastructure roadmap.
• Governance and lineage gaps: Alteryx workflows stored as binary XML in a proprietary format provided no native integration with the organization's Apache Atlas-based data catalog or column-level lineage tooling.

The MigryX Approach

MigryX began with a six-week discovery and complexity classification phase. The MigryX Discovery Engine ingested all 2,800 workflow files — including nested macro packages (.yxzp) — and produced a full inventory report classifying each workflow by tool composition, macro nesting depth, data volume characteristics, In-DB connectivity, and estimated migration complexity. Of the 2,800 workflows, 61% were classified as straightforward, 29% as moderate complexity, and 10% as high complexity requiring human review. This classification governed sprint prioritization throughout the 14-month engagement.

The core migration engine parsed each Alteryx workflow's XML structure at the tool-node level, extracting the directed acyclic graph (DAG) of transformations and the configuration parameters for each tool. MigryX maintains a comprehensive mapping library covering all 250+ Alteryx tool types, including the full Input/Output suite, Preparation tools (Select, Formula, Filter, Sample), Join family (Join, Find Replace, Append Fields), Spatial tools, Reporting tools, and the complete Predictive analytics palette. Each tool mapping was tested against the client's actual data to validate output equivalence before promotion to production.

Batch and iterative macros — the highest-risk component of the estate — were converted using MigryX's macro expansion engine, which analyzes the macro's control flow, resolves parameter bindings, and emits equivalent PySpark loop constructs or Databricks Workflow parameter sweeps. For the 38 most complex macros with recursive or conditionally branching iteration logic, MigryX engineers conducted manual review sessions with the client's SMEs to validate business intent before finalizing conversion.

In-DB tool chains were converted to native PySpark DataFrame operations with Databricks-optimized execution, eliminating the mixed-execution complexity of Alteryx's push-down mode. Delta Lake was adopted as the persistent storage format, enabling ACID transactions, time travel for audit requirements, and Z-order clustering on high-cardinality join keys — directly addressing the performance bottlenecks in actuarial batch jobs. The resulting code was deployed to Databricks Workflows for orchestration, providing a fully auditable execution history and native integration with the organization's Azure DevOps CI/CD pipelines.

Migration Architecture

Security & Compliance

The client operates under Solvency II (EU), NAIC Model Audit Rule (US), and Lloyd's Market Association data requirements. All migration activities were conducted within the client's private Azure tenant with no data leaving the client's network boundary. MigryX's on-premise migration tooling was deployed within the client's Azure environment, and all generated code was reviewed by the client's security architecture team prior to production promotion.

• Data residency: All intermediate and output datasets remained within the client's designated Azure regions throughout the migration process.
• Access control: Databricks Unity Catalog row- and column-level security policies were configured to match the role-based access controls previously enforced via Alteryx Gallery permissions.
• Audit trail: Delta Lake transaction logs provide immutable, timestamped records of all data modifications, satisfying model audit requirements for actuarial data lineage.
• Encryption: All data at rest uses Azure-managed keys with customer-managed key option enabled for the most sensitive actuarial datasets; data in transit uses TLS 1.3.
• Change management: All migrated code went through the client's standard four-eyes review and change approval board process before production promotion.

Results & Business Impact

The migration delivered measurable improvements across every dimension tracked in the program's success criteria framework, validated through 90 days of parallel production operation before full Alteryx Server decommissioning.

The $5.2 million three-year savings figure includes $3.1 million in eliminated Alteryx licensing and infrastructure costs, $1.4 million in reduced Alteryx Server administration labor (previously requiring a dedicated Windows infrastructure team), and $700K in avoided hardware refresh costs for the Windows-based Alteryx Server cluster. These savings are partially offset by increased Databricks compute spend for always-on cluster configurations, but the net position strongly favors the Databricks platform at the client's current data volumes.

"We had been living with the Alteryx estate for so long that we assumed the complexity was inherent to our workflows. MigryX showed us that most of that complexity was an artifact of the tool, not the business logic. The generated PySpark code was cleaner and more maintainable than what our own team would have written from scratch, and the performance improvements on our actuarial batches were a major improvement for our daily reporting cadence."

— Head of Data Engineering, Global Insurance & Reinsurance Group