Tech Transformation: From Proprietary to Open Source

Note

Transformation happens across both technology stacks and the people running them. The previous post was about Team Transformation. This post will cover the Tech Transformation that was happening at the same time. It doesn’t always happen that way, but it did in my case. Once again, the names of the people and the companies have been either left our or changed to protect peoples privacy.

This is a story about the tech transformation of a data center automation team from a almost completely proprietary tech stack to a completely open source one. So lets get into it…

The Proprietary Tech Stack

This story goes back a little ways. This is a data centers operations tech stack. It was comprised of several proprietary and enterprise open source systems. These systems came from companies like HP, Red Hat, and Microsoft for the most part. They were a tech stack run by a team of application admins that each were focused on a different part of this overall stack. The overall goal, provide data center operations for infrastructure including systems and networking, and the management of those systems configurations and so forth.

So while this stack has in it some open source, I’m listing it here in the proprietary tech stack because frankly, it required a certificate to be operational. Without a valid cert, YMMV and boy did it. I won’t get into which company, or why the cert mattered, but lets just say if you didn’t have a valid cert the YMMV part would break internal technical processes so badly that they were essentially stalled.

Thus the need to transform entirely away from a proprietary stack to an open source internally driven one.

The Open Source Tech Stack

The open source stack? It was a lot of things and there were a lot to choose from. We’ll cover how we got to this stack later. Here is a list of what was settled on:

• The Foreman – OS Provisioning

• Puppet – configuration management

• Spacewalk – Package mgt and config

• Chocolaty – Windows pkgs

• TincVPN – secure connectivity for our infra

• Capistrano – remote server automation

• Docker – for containers

• MySQL –for ETL / data storage and reporting

• Ruby – the chosen programming language of the team, among others for web gui’s

• Rabbit MQ – for message broker

-Subversion / Gitlab – for versioning

• Vagrant – for dev VM OS images

• OTHER STUFF – there is some more, but I don’t think its important to list it all here

Now I should note, that there are some things that just stayed proprietary. For instance, some of the infrastructure this stuff ran on top of was not open source. Things like VMware, and other proprietary IaaS like systems. For the sake of our story probably doesn’t matter too much.

So there it is.. the new open source stack largely identified. There were a few more things that were internally developed. We developed a service for grouping systems and another homegrown monitoring system. We can talk about those as we go, but since they were fully internally developed I won’t go into too much detail about them.

I should also mention that while I named underlying tech stacks, we didn’t necessarily use them just as they came. In multiple instances we made modifications. In most cases we contributed those changes back upstream to the open source project. In other cases, we simply kept it internally just to us. When we did that it was largely because the change was specific to our environments needs.

The Tech Transformation

So how do you go about executing a tech transformation of this sort?

You have to know why you are doing it, what you are replacing, and you need buy-in and support not just from leadership, but from your customers.

So how did we do that? We did it like this…

First, we took inventory of our proprietary tech stack. Then we made a list of all of its functionality. Then we poured through that functionality and prioritized it based on our internal use of that functionality.

Next up, we went on the search for open source systems that met those functional needs. We grouped them, we examined them, we compared them. We scored them based on our needs. Then we made a list of what delivered what functionality and why we made that choice.

Then, we took all of that information, examined our current proprietary environment and grouped things together that need to be transformed together to maintained a coherent operating environment. We also tested these ideas out, banged through them, poked holes. We documented our thoughts. Then we road mapped and time lined it all.

Now that we had all of this upfront data, we built our own pitch deck. Thats right, we were pitching this. We worked backwards. First we pitched our immediate supervisor. Then with them onboard, we immediately pitched our customer base in groups and sought feedback on the ideas shared.

Once we had the ideas shared and the feedback, we examined what was provided and made the necessary changes to the plan and reviewed this again with out immediate supervisor. Once they understood and were on board we once again, went to our customer base and pitched it including the reasons why we did or did not include any feedback we received. In the end, they were all on board and appreciated being included in the process and the decision making because it effected all of their futures.

Now with that all settled we needed to get this idea funded. We took that same deck and presented to the executives of our entire division. You know, the people with the decision making power to ensure we had the money to make this happen or not.

By the way, lets not forget that all along the way we performed calculations on the money that would be saved. We projected an initial $30 million a year savings. This got peoples attention especially since we already had and would provide the justification for such numbers.

Once those executives had heard our pitch, understood that we already had the support of our customer base, and buy-in from that customer base. We had the go ahead.

This work required a team transformation as well. We talked about that in the previous post, so we’ll leave it out of this one.

The Timeline and Continued Buy-In

All transformation takes time. In this case we had segmented each grouping of our delivery path and our goal was by end of year to be operating on the new open source based systems entirely.

We did this with team transformation, so the skill sets required grew into the team as the tech transformation began. The entire work required updates to our customer base and transition times for each grouping as they were delivered.

This was accomplished by providing regularly projects updates to the customers. We would have well over 200 people on these presentation calls. It was amazing. The excitement was catching for the whole organization. These updates happened at both a monthly and a quarterly basis. They always shared the plans and the timelines, and the money savings along the way.

Keeping everyone in the loop, kept the buy-in in place. We had no detractors. Quite the opposite. Many were finding ways to report about our status in their own updates to be a part of the success.

The Return on Investment (ROI)

Here is a breakdown of the costs and monetary results based on current enterprise data.

1. Upfront Migration Costs (The Investment)

While the software license itself is often free, the total cost of migration can be substantial. You are generally switching from a product cost / support contract to little to no product cost / the need for complete internally driven support.

Enterprises should budget for these one-time expenses:

• Implementation & Integration:

This is often the largest cost. It involves configuring the software, integrating it with legacy systems, and potentially hiring specialized consultants. For complex systems (like ERP or CRM), implementation can range from $50,000 to several million dollars depending on scale.

• Data Migration:

Moving data from proprietary formats to open standards often requires custom scripting and cleaning. This can add 15–25% to the implementation budget.

• Customization:

Unlike proprietary “black boxes,” open source often requires tailoring to fit specific workflows. Development costs here vary wildly but are a key budget line item.

• Training & Change Management:

Staff must be retrained on new interfaces and workflows. Budget for 10–20% of the project cost for training to ensure adoption.

• Dual-Running Costs:

During the transition, you may pay for both the old proprietary system and the new open source stack simultaneously.

2. Ongoing Cost Savings (The Return)

Once migrated, the operational expenditure (OpEx) profile changes dramatically:

• Elimination of Licensing Fees:

This is the immediate win. Enterprises typically save 20–30% on total IT costs in the first year simply by removing per-user or per-core licensing fees. Over 3–5 years, this compounds significantly.

• Reduced Vendor Lock-in:

You avoid forced upgrades and arbitrary price hikes common with proprietary vendors.

• Hardware Efficiency:

Open source solutions (especially in infrastructure, like Linux or Kubernetes) often run more efficiently on commodity hardware, reducing infrastructure spend.

3. Monetary Results & ROI

Industry research highlights strong financial returns for organizations that manage the transition well:

• ROI Ratio:

Studies indicate organizations can achieve up to 4.8x ROI by actively leveraging open source software compared to remaining on proprietary stacks.

• Macro Impact:

On a broader scale, open source adoption is credited with saving the global IT industry trillions in licensing costs, allowing capital to be redirected toward innovation rather than rent.

• Break-Even Point:

Most enterprises reach a break-even point within 12–18 months. After this period, the cumulative savings from avoided licensing fees typically exceed the initial migration investment.

4. Hidden Costs & Risks to Watch

To ensure the financial model holds up, account for these ongoing responsibilities:

• Support Contracts:

While the software is free, enterprises often pay for “Enterprise Support” (e.g., from Red Hat, Canonical, or specialized vendors) to guarantee SLAs. This is usually 30–50% cheaper than proprietary licenses but is still a cost.

• Internal Expertise:

You may need to hire or train staff to maintain the system, as you can no longer rely solely on the vendor’s support desk.

• Security & Compliance:

The responsibility for patching and compliance auditing shifts to you. Automation is key here to keep costs down.

Summary: The Financial Verdict

Our Tech Transformation Results

In our case, the results were staggeringly good. Part of that was surely based on the overall buy-in from all involved and their dedication to its delivery. Here are some numbers that we experienced solely around the tech transformation.

We experienced:

• A Weeks to Minutes improvement in deployment times across all data centers

• Fully automated environment config and on-demand promotion from dev-prod

• Full packaging automation

• Automated reporting and dashboards

• On-deployment auto configuration of monitoring systems for deployed objects

• Mass Remote Execution across huge swaths of the infrastructure as defined by meta data was fully actionably and resulting in atomic actions across the infrastructure

• A full automation services layer that sheltered the customers from the need to know what tech was driving the solution behind the scenes

• The ability to upgrade out entire infrastructure without impacting our customers current use

• Massive $30M Year over Year savings in costs of proprietary contracts and vendor services

Recommendation:

The move is readily justified if you have the ability to absorb the initial implementation hit. For small teams, the upfront cost of expertise might outweigh the licensing savings. Your experience doing this is in part team member capability based. For mid-to-large enterprises, the 20–30% reduction in ongoing IT spend and the 4.8x ROI make a compelling case, provided you invest adequately in training and integration to avoid operational failures.