Migrating FIX Platforms: Best Practices
So you want to migrate your FIX infrastructure
All trading infrastructure has an upgrade cycle and FIX is no exception. But as FIX connectivity is often seen as a must rather than a competitive advantage, the upgrade cycle is a long one. The accretion of configurations, customizations, one-off sessions, routers, integrations, reports, archives, translators, schedules, scripts, and even raw domain knowledge in your Operations employees’ heads presents a unique challenge of technical inertia.
Your first task is to answer these questions.
- What’s the biggest pain point today?
- What’s the risk of migrating?
- What’s the risk of NOT migrating?
It’s rare to have a serious FIX migration initiative without some specific driver. Is onboarding taking too long on the current platform? Is monitoring or transparency lacking? Are older tools failing to scale? Is performance degraded? Are new business lines held up by an aging platform?
The Real Cost
The cost of addressing these pain points is not necessarily immediately apparent. There are the tangible costs: data centers, servers, salaries, licenses, etc… But these are often far exceeded by the intangibles.
Opportunity costs are easy to overlook, but they can have a serious impact. Is a new line of business delayed by excessive onboarding timelines? Is aging infrastructure leading to increased latency and trading losses (slippage)? Are your most productive employees spending undue amounts of their time on nonproductive maintenance of old tech instead of your core business?
Risk of Migration
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.
Risk of Inaction
The risks inherent in a FIX platform migration do not exist in a vacuum. They are counterbalanced by the risks 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.
Migrating a Platform
Once you have identified your needs, risks, and goals, a migration can begin. While the details are highly specific to your particular use case, the overall steps are the same anywhere. Consider this a blueprint of the best practices to reduce your risks and successfully migrate to a modern FIX platform, regardless of where you’re starting.
1. Monitor and analyze current FIX environment
The FIX platform you’re replacing needs to be monitored in order to be understood. Complete documentation is rare, even in sophisticated firms, and is rarely up to date. Exceptions accrue over time.
The most accurate Rules of Engagement document you have is a month of your own FIX traffic.
2. Document baseline workflows
From the actual environment, identify your most common workflows. There will almost definitely be exceptions, possibly many. But there should be a common core. Start with that. The base workflow will serve as the proof of concept, and the new system should be designed to handle or eliminate edge cases better.
3. Perform qualitative analysis to select new platform
Don’t shoot in the dark. Formalize the decision-making process based on your needs, your risks, and the size of your organization. The level of formality is heavily dependent on you. For a small migration, a simple spreadsheet matrix comparing your needs and the capabilities of possible solutions is often sufficient. For a large institution, the rigor benefits of a full formal RFP may outweigh the agility of a simpler process.
Whatever you do, consider both internal and external solutions. More importantly, hold them to the same standard. No solution will be a perfect fit: everything is a list of pros and cons. Prioritize your criteria: are they must-haves or nice-to-haves?
Some potential criteria include:
- Platform requirements (OS, APIs, FIX versions)
- FIX workflow and processing requirements
- Functional requirements of platform
- Project requirements
- Risk mitigation and deployment options
- Vendor Evaluation
The point is to write down all of your concerns, prioritize them, and evaluate every potential solution by the same rules.
4. Stand up new environment
You have your baseline workflows. Implement them on the new platform. The sooner you have a proof-of-concept environment up and running, the smoother everything will go. This is an opportunity to begin many of the broader migration tasks (e.g., monitoring, HA/DR, stress testing, integration testing, etc…) in parallel.
We at Flyer have found that the time it takes to get this initial environment up is a good indicator of the overall health and success of the migration as a whole. You’ll catch problems early, leaving you time to solve them correctly.
5. Black box testing
For the baseline workflows, use a tool to build workflow simulations. This should be easy: you already have all of your FIX logs. If nothing else, use these logs to “replay” real flow. The more automation, the better. Your goal is to confirm that the new environment behaves, for all intents and purposes, the same as the old environment.
Once the baseline workflows are confirmed, start throwing entire days’ replays, including the edge case/exception workflows. Anything that doesn’t behave as expected can be isolated, documented, and integrated into the new platform in a controlled and uniform manner. Think of this a flavor of test driven development.
6. Initial migrations
You want to identify some combination of your most valuable connections and your most problematic connections, and start with these. Valuable connections are those that drive your revenue, and should be migrated carefully. Problematic connections are the ones most prone to issues, and most likely to stress the new environment or require changes.
These initial migrations can be given the white glove treatment, and some manual labor is expected. They serve as a high-touch dry run, and pave the way for bulk migration.
7. Bulk migration
The migration path will have been cleared and tested with these initial migrations, leaving a high confidence in the health of the new platform. Now it’s simply a matter of using automated or semi-automated tools to migrate the rest of your connections in bulk. In practice, this phase tends to take about as long as the initial migrations: more connections are migrated at once, but each is given less manual care.
8. Effective maintenance
Make sure you don’t end up in the same pre-migration boat five years from now. A new platform, no matter how sophisticated, can turn into a mess over time for all the same reasons you migrated in the first place. Deploy tools, policies, and procedures to ensure that the environment remains as pristine and usable a decade from now as it is today.
Flyer has a wealth of experience performing these migrations. This guide, while very high level, is an overview of our methodology. The devil, of course, is in the details. Regardless of whether you migrate entirely with internal resources, outsource the entire migration, or straddle that line, you need to ensure that you have the right tools to succeed.
Flyer offers a full suite of FIX tools tuned to this purpose. Our FIX Engine is a state-of-the-art platform deployed around the world. Our Daytona Trade Monitor tracks, analyzes, and archives FIX traffic, and also has extensive FIX Rules of Engagement auto-certification capabilities. Our Ignition FIX Testing Tool captures and replicates full FIX workflows, replays FIX logs in bulk, and validates FIX traffic.
More to the point, Flyer provides migration as a service. Leveraging our expert FIX team, our home-grown FIX software, and our wealth of experience performing these migrations, we’re a powerful resource at your disposal.