We’ve discussed migrating FIX platforms before, but on a high level. This is part one of a longer series of articles covering the details and logistics of FIX Migrations.
What is the Business Driver?
It’s rare to have a serious FIX initiative without some specific business driver. FIX infrastructure is never upgraded just for the sake of it; in addition to operational risk, there is opportunity cost, be it in man hours or budget dollars. Understanding the business need for the change underlies every aspect of the process.
Is onboarding taking too long on the current platform? New platforms accelerate onboarding. Is monitoring or transparency lacking in light of new regulations? New platforms support regulatory guidelines. Are aging tools failing to scale and holding up new business opportunities? New platforms are global and responsive. Is the operational risk of the status quo becoming unacceptable? It may be time for a change.
Define, in clear terms, the business goal of the migration. What problem are you trying to solve? How will the company perform better once the migration is successful? If the answer is primarily technical, then it’s probably not the true driver. There must be a business need somewhere.
Cost vs Benefit
On one hand, there is the cost of migrating the FIX platform. On the other hand, there is the direct benefit to the company. It seems straightforward. A well understood business driver and clearly defined goals allow for some level of formal cost/benefit analysis. But, be wary of putting too much stock in the numbers from a quantitative analysis. Neither the costs nor the benefits are all likely to be readily apparent.
The direct benefits of a FIX migration should align 1:1 with the stated goals of the project. Some of these are easy to see: a lower licensing fee, a leaner FIX staff, a newly enabled workflow, etc… Others require some comparative analysis. Is onboarding faster? Is latency lower?
Before any migration, define not just what should be improved, but how you will know it is improved. Without some reasonable metrics, even simple ones, it will be difficult to understand the true progress of a migration, or even to compare different solutions.
Generally, direct costs are the total of fees and resource hours spent performing the migration, as well as the ongoing cost of long term maintenance. They can be easily compared to the current FIX platform’s costs.
A common mistake is to see a higher cost of the new compared to the old without properly accounting for the Direct Benefits. If a migration was necessary, then comparing the direct costs of the new platform options is a better measure than comparing the direct costs of the old and new platforms.
Many FIX platforms have a wide range of features. Even as you evaluate them in light of your stated goals, it’s worth considering adjacent spaces that may benefit. For example, a monitoring tool that comes along with a new FIX platform could be deployed to existing and legacy environments. A FIX certification tool could also be used for testing, QA, or other teams.
There can be even more subtle benefits to upgrading. Legacy platforms accumulate a good deal of spaghetti configuration, proprietary knowledge, and poorly documented customization. The clean slate of a new platform is a valuable opportunity to modernize the entire support structure around FIX.
A new platform may have hidden costs related to supportability, expansion, or even vendor lock-in. But most “hidden” costs lie in the old platform you’re hoping to replace. Incremental maintenance, staff turnover (and the resultant knowledge transfer), outages: these can add up.
When estimating the true cost of keeping an existing FIX platform up and running, it pays to do some homework around the invisible work operations, development, and support teams may be doing that has become routine and thus invisible. It’s possible a new platform will free up resources you didn’t realize were available.
Cost vs Risk
The risks inherent in a FIX platform migration do not exist in a vacuum. They are counterbalanced by the risk of keeping your existing infrastructure. Complex aging systems are increasingly prone to failure, vendors stop supporting old versions of their software, employees holding extensive domain knowledge leave. These risks can be mitigated, but they will only grow.
No infrastructure change is without risk. The risks of FIX migrations are not unique, and like any technology, risks can be mitigated. You have to systematically identify the specific risks of upgrading your particular platform, determine how severe they may be, and integrate concrete plans for addressing them into your overall migration strategy.
This involves, at least on a high level, documenting your current workflows. How are systems connected? Don’t worry about the details at this stage: that comes later. The key is to identify the scope of the potential risks.
Equally important is the risk of continuing operations as-is with the current platform. These are often underestimated. Legacy platforms are a significant source of technical debt. The longer you remain on a limited platform, the more it will cost to adapt to a changing marketplace. The short-term risk of performing a migration can in the long term heavily reduce your overall exposure.
Understanding the risks inherent in your current FIX platform is crucial. Are there key employees or diffuse institutional knowledge required to keep it running? Have configurations diverged from standards or amassed undocumented customizations? Is the version in place still supported by the vendor?
In the end, risk functions as a cost. Changes that reduce risk effectively reduce cost. A successful migration to a modern FIX platform, well planned and well executed, has the potential to be a solid foundation for supportable future expansion.
The next article in the series will focus on the concrete steps needed to begin planning a migration. These center on understanding what you have today in your current FIX platform.