In this blog article, our Head of Professional Services, Sönke Sprink, shares the secret to a successful software migration project.
When the time is right for a software migration #
“Never touch a running system.” That sentence is a favorite when you want to ignore the weird smells or sounds coming from the machine room. As long as nothing explodes, a “functioning” system shouldn’t be interrupted.
However, when it comes to business, it’s not enough for things to run but to run optimal.
In my daily work, I deal with a lot of software migration projects, and I’ve supported countless customers when they migrated to our Frisbii Billing & Subscription Management platform. That’s how I know that businesses like to postpone switching to a new software as much as possible.
In many cases, it’s just assumed that things will turn out ok.
At the same time, internal logic and processes that need to be managed by the existing software are not really transparent. Often, businesses don’t even know what is currently going wrong and what could be optimized.
When we and our partners support our customers with their software migration, we often discover hidden problems and hurdles that our customers were never aware of.
A few examples:
- The number of contracts that receive services but are not being paid
- The number of customers who have two or more parallel contracts
- The number of inactive customers and their outdated contracts that bloat data segments
It is both fascinating and shocking how often software migration uncovers processes that have been forced into inefficient software setups. I’ve experienced myself that a field for phone numbers was used to add info about the right delivery method for newspapers (via the letter slot, not the letterbox) because there was no other way to include the information into the system. And that’s often daily business: you work with what you have instead of asking if what you have is still enough.
Data security is another hot topic that can cause unpleasant surprises whenever legacy systems, and their data archives are evaluated in preparation of a software migration.
Because of these and many other reasons, I always recommend to take inventory of your data regularly, not just when you need to migrate it. That way, it will be much easier to evaluate your existing systems and processes regarding efficiency, data security, transparency and scalability. After all, the reasons why you need to switch your subscription management and billing platform can vary:
- The system causes more and more problems and operational downtime
- The system doesn’t receive any new updates and/or is too high-maintenance
- The system is too expensive or includes too many functions that are not used/needed
- The system can’t cover specific processes
- The system has turned into spaghetti code and it’s impossible to optimize it
- The system can’t be integrated with other necessary systems and tools
In the following, we’ll present the eight steps of an efficient, secure and successful software migration.
Setting a time table #
Every single one of the following steps takes time, and potentially a lot of time depending on the size of your inventory. Prepare a time table at the very beginning of your project and check during every single step/phase of the software migration whether you’re still aligned with that plan.
Consider that every single step might require not just one but more cycles.
The time table will help you to prioritize tasks and be able to access resources (external teams and service providers) when you need them.
Taking inventory #
The goal of your inventory is to create an export protocol that includes all contracts that need to be migrated as well as all contracts that should not be migrated. A lot of your existing data doesn’t need to be carried over and should be deleted – this is also mandatory for sensitive data for data security reasons. By the way, a healthy trim can also include systems and processes.*
- Which contracts should be migrated?
- How can you describe/define the products/services associated with the contracts?
- What are the price points for these contracts?
*Old contracts often contain terminology, data sets or structures that aren’t used in newer processes but are still included in your system. If you can delete these contracts, because they are not active or don’t have to be archived anymore, you can also remove any associated, outdated taxonomies, processes and system settings.
Ensuring inventory #
When ensuring your stock/inventory, you check that all the data listed for migration is complete. Additionally, you make sure that data processing works the same (or better) after your migration. You don’t want to lose any contracts or other data or generate entirely new data sets with the migration.
Your books from the last months, delivery lists, newsletter lists, etc. can help you to double check your export lists. Additionally, they provide information about the data logic that’s associated with the data.
Modelling #
After taking and ensuring inventory, you are able to add more details to your (until now) broad goals (e.g. optimization, automation, cost reduction). You do this by mapping your exported contracts to your planned products (subscriptions, memberships, etc.,).
- How should your future/new products be structured?
- What services/products do you want to offer?
This step can potentially include new decisions regarding your subscription plans and whether you want to expand them, reduce them or change them in other ways. We’ve had quite a few customers that took the software migration as an opportunity to rethink their existing subscriptions and make them easier for customers while simultaneously uncover more revenue opportunities (e.g. via all-access-subscriptions, low entry-level subscriptions, new paywalls, etc.).
Testing, testing, testing #
The error rate up until this point is pretty much zero up until now. That being said, the entire migration should run inside a test system starting from step 1.
The test environment is crucial to see if contracts act the same way in the new environment just like they do in the – at this point still active – legacy system.
- Are customers getting invoices at the right time?
- Is the invoice data correct?
- Is all transactional communication correct?
- Do all contracts receive their product/service?
Testing will be repeated until you can’t find a single error and all contracts are delivered to the testing system. This way, you ensure that the live migration goes as smooth as possible.
Production test #
After testing is done, you move all configurations to your live system and test them first to make sure that:
- everything is properly configured
- all systems are integrated and connected
- every payment goes through
Security net #
At this point, your legacy system was still fully operational (billing, delivery). Now is the time to check all security measures to see if you can stop/pause your billing while simultaneously activating your new system.
You also check if delivery from both systems can be ensured and you define when contracts can be stopped in the legacy system (once they are successfully moved to the new system). If your legacy system is not an inhouse/on-premises solution, it can happen that this process will be slightly more complicated if the vendor does not want to or can’t support your software migration.
Examples:
- There is no automated way to end individual contracts
- There is an export limit from the legacy system
In these cases, it is good to have a plan B (and C, and D). In many cases, you can ensure successful customer delivery by taking over users and entitlements into your new system. Billing can often be postponed a little, leaving a few days or even weeks between the export and the complete import of your contract data.
Live migration #
After importing into your live system, security nets will be removed one by one, so you and your team can check individual functionalities, deliveries and invoices carefully and without stress.
Even though many companies think that all these steps are incredibly time- and resource-intensive – software migration is a standardized project that can be done a lot faster than imagined. Security nets and automatic testing protocols can further simplify testing and reduce any economic pressure.
After migration is before migration #
My personal recommendation after every migration is to continue regular data inventory to keep your data clean and make sure that your system runs efficiently and smoothly.
Today, more than ever, your data (quality) has a huge impact on your economic success.
Migration with Frisbii #
Migrating from your current subscription management, billing or payment solution doesn’t have to be a nightmare. Frisbii makes it easy to integrate, plugin and connect with API first, many no-code functionalities and a team and partner network that is happy to help you make the switch.
The Author
Sönke Sprink is Head of Professional Services at Frisbii and is highly experienced in supporting and consulting for migration projects for publishing and media customers for Frisbii Media. Connect with Sönke on LinkedIn.
