In this in-depth article about software migration strategies, we discuss the key roadblocks to enterprise or consumer software migration and provide 5 strategies to success and innovation.
Every few years, sometimes every few decades, technology stacks go through a major change.
Some examples of software migration strategies include the advent of the server with initial deployments as mainframes. In the 1990s, a new wave of multi-tier server architecture (web server, application server, database) helped Intel systems create a new wave of compute infrastructure, and applications, still with a focus on on-premise deployments. After this, cloud computing provided another major paradigm shift, which as of the writing of this post, the business world is still undergoing.
1. Understand the forces of resistance to migrations and upgrades in technology
When new technologies improve the productivity of people and businesses, it is critical to adopt them to stay competitive. At the same time, there are forces of resistance which often prevent organizations from making the switch:
Why change existing technology that works?
The term “business as usual” exists for a reason. Once an organization becomes comfortable with a way of doing things, it can seem like the most sensical course of action is to avoid disrupting it. However, if customers and the market are moving to new models, failing to adapt will eventually turn into a disadvantage. This is why software migration strategies are so important.
How will the new technology affect people’s jobs?
Individuals make decisions which impact their business, but also their career, and their teammates careers as well. There is wisdom in protecting people’s jobs. But at the same time, the world – the competitive business environment – is always evolving. Cloud technologies, for example, shift some of the legacy roles of IT to business functions (sales, marketing, service, operations). The CEO and the executive team need to consider how reshape their organization so that people’s careers are not a force of resistance, but instead a force of innovation to create new jobs for the new paradigm.
Will the new technology deliver as anticipated?
A valid concern when implementing a new technology revolves around the ability to deliver. At the technical level, this can include ensuring there is no data loss, no downtime, no decrease in productivity or functionality. We will address how to alleviate this concern in the next section.
2. Create a strategically compelling and technically safe technology migration plan
Migrations can be highly successful, bringing an organization into a new state of competitiveness, with new tools, and new ways to delight its customers.
Define the vision for the business and for people
A technology migration happens through people and for a purpose. By articulating to each team the purpose, the urgency and the intended outcome of the technology migration or upgrade, the management team will explain why it matters to everyone.
The plan needs to help those in the organization whose role will change from the technology upgrade, and how the company intends to help transition past goals and responsibilities, to new goals and responsibilities, to support the new systems.
Find champions in the organization
This step applies both the organization doing the change, as well as the technology vendors supplying the solution. Change happens with the impulse from top management, or from middle managers who have the leadership skills to see the benefit for the company, and drive the change.
Champions are the organization’s change agent to a better version of the company. They work through their direct area of responsibility, as well as influence other departments outside their direct oversight. Think Finance, Legal, Sales, Services, and so on.
Upgrade the existing system with new addons or APIs
Many people tend to think of a software application as one indivisible unit. If you are a developer, you know it is often not the case: an application often includes many building blocks. For example, it is common practice for applications which have lots of queries to include a “read only” copy of the master database. The master does reads and writes, but in order to prevent overloading it with queries which only do reads, the replica exists for this reason.
Another example can be user engagement and marketing automation. If you have an existing system with lots of customer data, and you are not ready to migrate it to a modern stack, you can create application programming interfaces (API) which a new system could ping, extract a bit of information from, and take it from there. It could email users, send them a phone notification, create a post on social media, and so on, as an addon component.
In essence, you add new technology on top of the legacy stack to start the modernization process. Instead of a full-on migration, you create a hybrid stack first.
Deploy the new technology on application front-end first, back-end second
Something similar consists of taking the main concern about migration: risking data integrity and data loss. Even if the risk can be mitigated and essentially eliminated by making backups and rolling back if necessary, sometimes the migration project gets stuck at this stage.
Many cloud migrations, or migrations from an old to a new stack, are done in stages. Since the data resides on the back-end of the system, leave this piece alone for the time being. Bring the new technology on and find a way to deploy it only on the front-end.
A front-end is easy to turn on, and turn off. You can test it, go live, and revert back to the legacy system in no time, since you are not altering the latter in this case. It gives a wonderful opportunity to migrate in a step-wise approach.
There are many ways of accomplishing this technically, from adding a layer at the routing and networking levels, to aggregating the data inside the web browser using javascript.
Large companies: roll out new technologies with new teams
One final path to enterprise software migration: big companies sometimes feel their size is a disadvantage to being nimble. Use size instead to your advantage. A large organization often has new teams, subsidiaries in regions, or vertically integrated suppliers which have independence of decision.
Roll out the new technology in a pocket of your enterprise, be it that new team of 5 or 10 people, or a subsidiary. Let them take the leadership opportunity and show the rest of the organization that it can be done. Sometimes, migration is not about the technical aspects, as much as it relies on developing a technological comfort zone.
Leave a Reply