A comparison of data migration for client onboarding and systems upgrade.

Client onboarding - key considerations:

When a product owner decides to move data processing responsibility to a new administrator, the decision is likely to have been driven by the administrative service cost or the level of service quality being delivered to active customers. Either way, the focus of the product owner is likely to be on the ability of the new service provider to process transactions efficiently and effectively for the active accounts, so that in turn is likely to have been central to establishing the new contractual terms and conditions. The significance of the historic customer data, potentially for customers who have long ago ceased to be active, sometimes will be overlooked. What is more, having made the decision to change administrator, the product owner is likely to be keen to conclude the transition as soon as possible.

Internal systems upgrades - key considerations:

When a data administrator decides to upgrade systems to improve service delivery or reduce administration costs, the objective will likely be to maintain or enhance service delivery levels as the customer data migrates to the new system. In these circumstances, the product/data owner may not even be aware of the systems changes if there is no effective change to the service being delivered or any significant risk associated with the transition. So implicitly it is likely that the historic data will be considered as equally significant to that which is associated with currently active customers. Indeed, the developers of the systems upgrade should have considered the structure, volume and quality of the historic data when analysing and building the new solution.

What is the significance of data protection legislation in these circumstances?

The roles of the product provider and the third-party administrator are constrained by data protection legislation if the customers are individuals with rights under that law. In this circumstance, the product provider would be the Data Owner and the third-party administrator would be the Data Processor. Normally the Data Owner would have committed to the retention of their customer’s data for a period of time after the customer becomes inactive, and it would be their responsibility to ensure that any third-party administrators that they utilise manage the retained data accordingly.

How does this influence the process of planning and executing the data migration?

In the case of an internal systems upgrade, the need to migrate all historic data is driven by both expectation that service delivery is not degraded and the need to retain data as per the rules defined in applicable data protection notices. As there will be pressure to decommission the data store of the historic system, there will often be little option but to migrate all the data. The complexity and lead time of this activity will largely depend on how thorough the systems developers assessed the structure, volume and integrity of the historic system when they were building the upgraded solution. Our experience at Piers Solutions Ltd is that the pressure to deliver upgraded systems quickly will sometimes result in some historic data being incompatible with the target system or requiring very complex transformation.

In the case of data take-on to onboard a new client, there is critical need for the new administrator’s sales and legal teams to recognise the significance of the historic data explicitly in the contractual and service level agreements. This will need to be handled carefully with the clients, as challenges may emerge only once the details of the historic data are analysed. The option to migrate all historic data will of course still exist and, if a data exchange standard has been established, this may well be feasible. However, where historic data integrity fails to conform to the requirements of the target system functionality and where the cost or lead-time of resolving the problems is prohibitive, the option of descoping some of the historic data from the migration becomes a more attractive proposition. But if this option is to be followed, the retention and management of the unmigrated data will still need to be addressed by the client and both the old and new administrators. For instance, it is likely that data retention rules will require ongoing data maintenance by the previous administrator and the new data processor will need to establish processes that allow for client customers to trace and potentially view the old data, should they be approached with a legitimate data access request.

Conclusions:

Data migrations relating to both a system upgrade and the onboarding of a client by a third-party administrator are sensitive to the preceding project activities, in particular the extent to which the necessary data transfer has been considered in the early phases of the work. The constraints that are imposed by, often infrequent but important, scenarios relating to data protection rules have a significant bearing of the scope of historic customer data that must be migrated. If minimisation of the lead-time for migration is a priority for the overall project, it is crucial that the scope of data to be migrated is reduced as far as possible. However, the business significance of any such narrowing of scope must be considered.

Pier Solutions Ltd approach to data migration is geared to the engagement of the necessary stakeholders and the consideration of such matters at the earliest opportunity. Please contact us to discuss your requirements if the challenges described here are applicable to your projects.

Contact Us