The Customer

A large U.S.-based financial company within the Fortune 250. They provide retirement, investment, and insurance products to both corporate and individual customers globally. As a leading provider they manage over $750billion in Assets with employees across more than 25 countries.

The customer engaged Iowa-based technology and management consultancy, Lean TECHniques, to help modernize an acquired application used in the Employee Stock Ownership Plan (ESOP) part of the business. Lean TECHniques specializes in IT modernization, and as an AWS Advanced Tier Partner, they work with technology leaders and teams to implement AWS-based cloud, data, and AI capabilities. Lean TECHniques has over 15 years of experience helping customers improve delivery practices, strengthen teams, and build the capacity to keep learning and adapt over time.

The Challenge

The immediate goal for the customer was to move the platform off its legacy footing and into AWS, but the wider ambition was bigger than that. They needed a scalable foundation for the application, the ability to move faster, and a cleaner path away from older internal systems and vendor dependency.

The team handling the work was relatively small, with around five engineers focused on this project, but the scope was substantial. They were taking ownership of a third-party application written in PHP with some C++ components on the back end, moving it from an on-premises MySQL environment to PostgreSQL on AWS, and building a more reliable way to manage releases at the same time.

When Lean TECHniques began working with the team, the deployment process was a major source of friction. Database changes were being handled manually. Schema changes were run by hand. Deployments were tied too closely to individual machines. And when something went wrong, the team often had to restore from a static backup and piece together which scripts needed to be reapplied. That slowed progress and made it hard to trust that changes would move cleanly from development to staging and production.

As Joshua Angolano, Principal Engineer at Lean TECHniques, explained, the team was working through the kind of transition many engineering organizations face — adopting a new database platform while also moving to the cloud and modernizing how they delivered software. “Our client’s team was stuck in that swirling state — heads down deploying, knowing they needed to move to the cloud but with no idea where to start.”

That combination of legacy processes, cloud migration and a live modernization effort created a clear requirement. The customer needed a database change process that was repeatable, easier to govern and able to keep pace with the rest of the application as it moved into a new environment.

The Solution

Lean TECHniques approached the work the way the consultancy approaches all engagements: build the team’s capability alongside the technical solution. The migration mattered, but a team that could lead the next one mattered more. “We see ourselves as an enabler for teams,” Joshua said. “I always start with the simplest solution that works.”

For database change management, that meant introducing Redgate Flyway early in the migration rather than letting manual deployment habits become embedded in the new platform. Joshua had used Redgate Flyway before and already knew that it was the solution to “deliver quick, repeatable deployments.” Just as importantly, he felt Redgate Flyway fit the way engineers already worked. “Redgate Flyway meets the engineer where they’re at, as opposed to you having to meet the tool where it’s at.”

Lean TECHniques introduced Redgate Flyway through a proof of concept, showed the customer how it worked, and got buy-in quickly. “Once they saw Flyway, it clicked. They were like ‘Oh yeah, that’s easy – just create a new version and deploy.’” Joshua said the team had it up and running in less than a day.

From there, Lean TECHniques helped the team build Redgate Flyway into a more modern CI/CD workflow. They moved the application to GitHub Actions with cloud runners and created an AWS Lambda function in Kotlin to run Redgate Flyway commands inside the secure boundary of the target environment. This allowed database deployments to be triggered as part of the pipeline, without relying on manual execution or having to manage complex network configurations to the secure network segment. This decoupled architecture allowed secure deployment while also using external cloud hosted services.

The new approach also brought database and application delivery closer together. Instead of treating database changes as a separate task, the customer could deploy the application code and the database in the same overall process. That mattered because the application itself was being reworked to run in a cloud-native model, so keeping those two sides aligned reduced friction and made releases easier to manage.

Governance improved as well. Changes were versioned in source control, linked to pull requests and Jira tickets, and reviewed through the customer’s existing processes. For a large financial services organization, that gave the team not just a faster process, but a clearer and more auditable one too.

The Results

The most immediate gain was speed. Before Redgate Flyway, deployments took roughly 12 hours. After Lean TECHniques worked alongside the client to introduce the new deployment model, deployments dropped to around 20 minutes. As Joshua noted, “most of that time was tied to building C++ libraries rather than the database deployment itself.”

The customer also gained consistency. Instead of regularly relying on backup-and-restore cycles and manually reapplied scripts when something broke, the team could use the same structured process across environments. Joshua said the customer went more than a year without needing a backup-and-restore event in production after the new approach was put in place.

That consistency had an operational effect beyond simple deployment timings. Because Redgate Flyway became part of the CI/CD pipeline, database changes no longer sat awkwardly outside the rest of the delivery process. The application and database moved together, which gave the team more confidence as they modernized the platform and reduced the risk of environment drift between development, staging and production.

The new process also fit the customer’s compliance needs more comfortably. Instead of a release depending on who ran which script and when, the work was now traceable through source control, pull requests and ticketing. For a financial services organization, that level of visibility mattered just as much as the time savings.

For the customer, the value of the project was not only that Redgate Flyway solved a technical problem. By working with Lean TECHniques, the team was able to successfully learn and implement AWS and PostgreSQL, while taking ownership of a third-party application – building real internal capability, skills, and confidence along the way. That confidence translated into a practical way to move forward with more control and less risk. The result was a modernization effort that became easier to scale, easier to audit, and much easier to repeat.

The impact included:

• Deployment times reduced from 12-24 hours to around 20 minutes
• Database and application changes deployed together through CI/CD
• No requirement for manual script and backup restores over the last year
• More consistent releases across development, staging and production
• Better traceability through source control, pull requests and Jira
• Greater confidence for a team modernizing both its application stack and database platform

Looking ahead

This project was part of a broader shift to AWS across the customer organization, and Lean TECHniques had supported similar migration work elsewhere in the business. For this team, though, the immediate task was clear: modernize a core acquired application, make it workable in the cloud and create a delivery process that would support future growth rather than slow it down.

With Redgate Flyway in place as part of that foundation, the customer was in a much stronger position to keep modernizing the platform, reduce reliance on older systems and support the next phase of the application’s life.