Migrate Systems & Services

Data and integration services migration is required when a system or service is moved to a new technology. Migrating systems and services is an activity all organisations generally find themselves engaged in at some point. This activity can be triggered by:

Adoption of SaaS systems/technologies
Replacement/upgrade of a vendor application
Development of a bespoke application or microservices implementation
Consolidation of systems through merger or acquisition
Divestment of part of a business
Migration of API or integration services from one stack to another

Migration activities are an opportunity to amplify the value of an implementation, either in terms of operational costs or the opportunity for value that the migration surfaces. Realising that value is dependent on the migration activities and approach an organisation takes to it.

Benefits of doing it well

Eliminating existing limitations or flaws

Reduce the time and cost to achieve successful migration

Maximise the opportunity of the new state and the investment

Created a positive foundation for future innovation

How to tackle migration projects?

The following activities are fairly common amongst migration projects.

Reconciling the data models and producing a set of mapping rules for the key business objects shared between the systems
Audit of key features/functionality, business rules etc to be produced/replicated in the new technology stack
Understanding the limitations of existing data, architecture and functional terms and incorporating improvements into the new services
Optimising the new implementation to accommodate lessons learned from the previous
Data and architecture design for new world
Production of a canonical model and layered APIs to ensure you can plug and play systems in an architecture when a need to migrate arises

Whether it is a system migration or a migration of integration/API services, the first step is generally to audit what is there in terms of features/functionality, business rules and data to be replicated in the new technology stack. Reconciling the data models between the systems and producing mapping rules for the shared business objects is key. We generally find ourselves with buckets of data to migrate with rules for each bucket to migrate that data with varying levels of automation. Data quality, or a lack of it, is a core reason we end up with these buckets or categories of data. They are often driven by changes in business processes or key personnel over time.

Organisations generally look to address data quality issues, limitations in data, functionality and architecture during the migration activity. It’s an opportunity to optimise the new implementation, get data models and architecture right. Deploying a canonical data model during these activities through reimplementation of integration services can make migration activities significantly simpler to achieve.

Common mistakes made in migration projects

Migrating systems ‘as is’ often results in a migration of the existing limitations or problems with the legacy system. In an effort to not break a business process, organisations find themselves compromising the value of the new implementation. Thinking ‘that’s how it works’ instead of ‘this is how it should work’.

Failing to address data quality issues in the legacy data set because we believe it represents truth can undermine the faith users have in what they see or report from the new world. We’re implementing a new lens through which to view our data or see the truth in it. If we need the old lens, then it’s better to warehouse the data and legacy reports rather than compromise the value or trust in the new implementation.

Organisation often fail to adequately make provision for the downstream systems and services that have dependencies on what is being migrated. Either this or they make too much provision for it which leads them to not addressing issues in the underlying data model. There are ways and means in integration terms that we can make provision for downstream data needs without compromising the new implementation. The implementation of a canonical data model is an example of this.

Entirely, missing integration until the end is far more common than people would expect as well. If integration hits the risk register of a migration project, it normally does so because it was addressed too late in the project. It’s rarely the new system or service implementation that solves the business problem, it’s the way it is implemented. The application consultants you engage to deploy the new world need integration consultants to help them to be successful in implementation.

How Chakray can help

At Chakray, we specialise in data and integration with migration one of the most common and frequent initiatives we are asked to consult with. We help organisations of all sizes realise the value of systems migrations by engaging early on their data and integration needs in implementation.

Get in touch