How can FundGuard’s new era approach to migration and upgrades transform your software testing process? In this blog, FundGuard’s Diane McLoughlin and Erika Alter discuss the shift from traditional, exhaustive software testing to FundGuard’s innovative Blue/Green deployment strategy. As Diane will explain: By focusing on real-world results rather than theoretical test cases, clients can transition to new systems more smoothly, efficiently, and confidently.
EA: I recently sat on a panel about building brand trust, and a key takeaway was the importance of leading clients through new or unfamiliar systems. This resonated with me because it’s exactly what we ask of our clients: trusting us when we say, “Yes, this new approach is different, but it’s better.”
Thinking about your last blog on FundGuard’s approach to upgrades, let’s dive into FundGuard’s approach to testing software migration and upgrades and how we’re transitioning our clients away from legacy software testing. From your experience, what first stood out to you about our approach, and what have you learned that helps guide clients through this transition?
DM: The biggest surprise for me was just how different our approach is from traditional testing. In environments where multi-year upgrades were standard, I was used to intensive testing cycles—scenario testing, parallel testing—all done in a very structured, bottom-up way. At FundGuard, we focus on comparing outcomes in real-time parallel systems, rather than endlessly running individual test cases.
When you’re focused on the final results, there’s no need to rerun every scenario. This top-down approach completely shifts the traditional mindset of software testing.
EA: If the historical norm is to rely on hundreds of theoretical test cases for peace of mind, what do you say to clients who have become accustomed to that level of exhaustive testing?
DM: That’s exactly the challenge. Clients are accustomed to running a large number of pointed scenario test cases to feel secure prior to migrating their software or upgrading their code base. This creates a false sense of security, as scenario testing does not replicate their entire book of business and the nuances of day over day activity. Think of it this way: funds have a series of activities taking place each day, and if you create a pointed test for each of them you might consider that a good success criteria. However, you are missing the validation of the new code base when all of these activities are strung together to form a typical day. By using the blue/green approach, you have effectively run a real-time parallel of all your funds for every day during your testing period using a single stream of inputs.
Instead of testing each component separately, you’re running the software as if it were live and evaluating the overall result. It’s a shift from testing hypothetical scenarios to replicating real-world use.
EA: Re: upgrade testing, why can’t clients with legacy systems follow this same approach? Is it a limitation of their technology?
DM: With legacy systems, everything has to be rebuilt from scratch for each test cycle, and even then, it’s not as smooth. Our tech stack automates things like reconciliation and comparison. In older systems, they’d have to create manual processes for that, which makes it more time-consuming and labor-intensive.
For example, let’s pretend that a client of a legacy accounting platform was able to copy their entire production database after the close of business on Friday and load that into an empty database with the updated code before Monday morning (effectively starting Monday morning with both databases in the exact same place). They would then need to replicate every activity that took place in their production environment into their new code in exactly the same sequence, including both file based and manually processed actions. Once that is complete, extracts from both databases would need to be created, reconciled and all differences documented. To accomplish this for a single day would be a huge task requiring countless resources from both operations and technology. The risks of chasing false positives within the recon would be extremely high, as the likelihood of human error when loading or entering activity is high. Without an army of people, performing this type of real time testing exercise is not easy to imagine.
EA: So it’s not just about trust but also efficiency. What’s the biggest pushback you hear?
DM: The biggest hurdle is the mindset. Many clients have entire teams dedicated to QA testing, and those professionals are used to relying on their test cases. It’s hard to let go. I often use the Salesforce process as a familiar example. They push updates regularly without service disruption but when they first introduced their process, users were skeptical. Over time, trust in their process grew, and now no one worries about it. It’s similar here. Our clients are coming to understand that running fewer test cases doesn’t mean losing control; it just means working smarter.
EA: Let’s dive a bit into the migration process with FundGuard’s approach. Walk us through the process when clients move from their old system to ours. How do you reassure them during this transition?
DM: When transitioning clients from an old system to FundGuard, we run the two systems in parallel for a set period. It’s like having two engines running side by side. During this time, they compare key data points: Do positions tie? Does income match? Does cash reconcile? Etc. Once they feel confident that the new system matches the old, they can turn off the legacy system. We also work with clients to define exit criteria, often after a set number of days or a successful month-end process, so they are confident when it’s safe to fully transition.
EA: Is there a checklist or set of criteria clients should follow to determine when they’re ready to switch completely?
DM: Absolutely. Here are some examples of criteria:
NOTE: Considerations must also be made for explainable differences that may result from more accurate accounting within FundGuard vs. legacy systems’ use of workarounds for more complex security types.
Once these key elements are in sync or positive explainable differences are noted, clients can confidently turn off the old system and fully transition. The clients we’ve worked with have made the switch successfully, often faster than anticipated.
EA: It sounds like the shift is not just technical but also mental. Clients have to trust that this new approach will work.
DM: Exactly. Whether migrating to an entirely new system or upgrading a current system, the old approach, with its multitude of test cases, has provided a sense of security. But by running in parallel for a set time, you can achieve that same level of confidence without the heavy testing burden. Once clients experience this a few times, they realize the new approach isn’t just different – it’s better.
Ready to embrace smarter, more efficient software testing? Connect with FundGuard today to discover how our modern approach can streamline your transition processes and enhance your operational efficiency. Our team of industry experts has decades of experience implementing investment accounting systems at the world’s leading asset managers and servicers, and we are here to guide you through every step. Contact us for a consultation and take the first step towards transforming your investment operations.
Cloud-Natives and Blue-Green Deployment: The Next Evolution of Investment Accounting
Dispelling Myths About Frequent Software Updates
About the Author
100 Bishopsgate
18th Floor
London, EC2N 4AG, United Kingdom
Sign up for FundGuard Insights
Your use of information on this site is subject to the terms of our Legal Notice.
Please read our Privacy Policy.
