Migrating from legacy proprietary software to open source alternatives offers the allure of lower costs and freedom from vendor lock-in, or at least the appearance of those benefits. Such savings and independence can be elusive, and are highly dependent upon the legacy technology, use cases, and the commercial arrangements governing the tech, and the technical and financial goals of the migration.
Over the years, our consultancy has published extensively on a range of migration-related topics and engaged in hands-on migration projects. These projects involved embedded operating systems (RTOSes), development tools and frameworks, enterprise databases, network monitoring and management tools, and even semiconductor design and validation tools. Clients investing in such migrations include aerospace and defense contractors, semiconductor suppliers, embedded software vendors, and even financial services organizations.
Several years ago, a major client organization contracted us to evaluate ROI for migration from legacy proprietary enterprise software to open source alternatives. The client was a substantial organization, with an IT budget to match.
The client was also super security-conscious, as you'd expect from a a participant in any tightly regulated industry, and financial services in particular. Every team member with direct client contact was finger-printed and we were cautioned against even mentioning the client name not just to third parties but to other groups in our organization.
Project Phases
This exercise fell into two separate tasks:
Identify candidates for migration from an expansive portfolio of installed commercial proprietary software.
Develop a methodology for migration justification for a specific set of legacy off-the-shelf tools to open source alternatives, and make recommendations regarding those tools.
Technical compatibility was assumed to be reasonable, if not always optimal, e.g., migration from a legacy SQL database management system was assumed to be a relatively straightforward exercise (see table in the following section). The first task, however, made no attempt to characterize technology migration in detail
The following addresses selection of migration candidates, while a second blog will outline how to arrive at a methodology for justifying migration and choosing open source alternatives for legacy solutions.
Reviewing the Software Catalog
Under non-disclosure, the client granted our team access to a very complete list of applications in use, along with descriptions of the software (mostly functional categories) and life-cycle data. The life-cycle data was particular relevant, detailing versions, dates of deployment and whether the software was slated for end-of-life by either the vendor or the client themselves.
Legacy Software Typology
In this enterprise setting, the types of migration candidates fell into a wide range of functional buckets: database, development, data/analytics and half a dozen others.
Note that the chart uses line-item counts from the catalog, not necessarily actual license or seat count, access to which we were not granted.
For comparison, observe the following chart for an aerospace/defense contractor.
Whereas the types of candidate software for migration in an enterprise organization came from a large catalog and were mostly evenly distributed, those in an aerospace/defense organization represented a large swath from a smaller catalog, and were concentrated around certain types of tools. Note that in such an organization, the license counts for embedded software are mosty for development tools, not for deployment units, which can run into the tens of thousands and beyond.
Migration Metrics
In these exercises, we examined a number of parameters that impact migration viability and success:
Number of licenses or developer seats
Cost per license
Total spend
Migration Complexity
Migration Complexity
From a technical standpoint, the most interesting parameter was always complexity. We rated migration complexity as follows:
| Level | Rationale |
|---|---|
| High | Much or all code leveraging legacy technology must be rewritten for migration. |
| Medium-High | Legacy needs combination of re-writing and straightforward porting / re-integration |
| Medium | Legacy stacks built on standard technologies but with potential proprietary hooks and dependencies |
| Medium-Low | Minimal legacy dependencies but no one single migration path |
| Low | One-to-one porting with no/limited changes. Re-build/re-link/reconfigure |
Low-Hanging Fruit
The above-mentioned catalog provided a view of “low-hanging fruit” for potential migration. From the over 8,000 entries in the catalog, we were quickly able to identify several hundred line items, based on life-cycle and on a priori knowledge of available open source alternatives, which we narrowed down to about forty strong candidates, across the functional categories in the chart above
However, the catalog was missing three critical data points:
Licensing terms: perpetual, subscription, node-based, etc.
Acquisition scheme: stand-alone vs. bundled
Acquisition and maintenances costs of the software, including support, updates/upgrades, etc
Obtaining this additional information proved to be more difficult than any other part of the engagement. Many (if not most) of the commercial licensing agreements were negotiated and executed under NDA and did not reflect more easily obtained vendor list-pricing. Moreover, each line item in the catalog involved purchasing agreements executed by various departments across the organization, initiated by departmental IT teams and executed by multiple purchasing agents.
Ultimately, our team was able to obtain historical commercial information for less than half of the “short list” identified – still a substantial set of migration targets. For another portion of the catalog, we applied publicly-available pricing information – a reasonable starting point. The items identified were quite costly: our first swag revealed an annual spend of between $80 million for just the line items targeted for migration.
Reality Bites
But then inconvenient reality stepped in.
The largest vendor in the catalog, a supplier of database software and myriad other software categories, had negotiated an “all-you-can-eat” purchasing agreement to the tune of $20 million / year. Under this agreement, our client ordered, at will, from the vendor product catalog, for an unlimited number of licenses across all product categories from that vendor – databases, operating systems, middleware, BI and analytics, enterprise applications – you name it. While it proved a straightforward exercise to identify legacy software for potential migration for technical fit, it was near impossible to justify abandoning the sweet deals already in place.
This same challenge existed for other parts of the client software inventory and vendor set, to equal and lesser extents.
The client acknowledged the difficulty we faced in making more specific, actionable recommendations, given the combination of limited access to commercial terms and the most viable migration targets falling under a “software buffet”. There were also plentiful if less advantageous migration candidates identified in the exercise. The client thanked us for our work to date, promised to get back to us with a short list of preferred migration targets, and accepted out invoice.
Conclusion
When approaching migration from legacy/proprietary software, one's natural thought process tends towards tackling technical issues: integration, APIs, data formats, glue code, etc. - all essential elements to determine migration viability and execute porting and retargeting. However, without sufficient financial justification, or the force of sheer will, there is no point in exploring technical particulars of the migration process.
Next time – a well-specified migration.