Data Migration Services Explained.

Data migration is often sold as a weekend database copy. That framing is convenient, but it's wrong for any organisation whose customers, staff, reporting, orders or public services depend on the platform being available. A migration can complete without an error and still damage the business through missing records, broken permissions, interrupted workflows or data that crosses an unapproved border without oversight.

For UK scale-ups, SMEs and enterprises, data migration services should be treated as a controlled business-risk exercise. The technical transfer matters, but so do the decisions around discovery, continuity, reconciliation, security, retention and post-cutover ownership.

• Treat migration as continuity planning: Define how the organisation will keep trading, serving customers and reporting while data moves.
• Inventory before extraction: Legacy systems, duplicate records and undocumented dependencies create risk long before the first transfer starts.
• Design security into the move: Use classification, least-privilege access, encryption, audit logs, reconciliation and rollback controls.
• Map sovereignty across the lifecycle: Review primary databases, backups, replicas, staging environments, telemetry and supplier support access.
• Choose the migration pattern deliberately: Rehosting may reduce change, while replatforming or rearchitecting can deliver a better long-term foundation at greater delivery risk.
• Demand evidence, not reassurance: A credible partner should demonstrate dry runs, business-process testing, recovery criteria and post-migration support.

Key Takeaways and the Reality of Platform Moves

The common advice is simple: back up the database, schedule a quiet weekend, move the records and switch users to the new system. That approach only works when the data estate is small, well documented, structurally consistent and disconnected from critical operations. Those conditions are unusual.

The UK Government's 2025 State of Digital Government review estimated that legacy systems represented approximately 28% of central government departments' technology estates in 2024, compared with 26% in 2023. The proportion varied across public services, from roughly 10% to 60% in police forces and approximately 10% to 50% in NHS trusts, with some organisations reaching 60% to 70%. Around 15% of respondents couldn't estimate the size of their legacy estate, according to the State of Digital Government review.

That matters because an organisation can't safely migrate what it hasn't discovered. Unknown integrations, undocumented exports, stale user accounts and conflicting definitions of a customer or case create operational exposure during cutover. In the same review, 25% of surveyed organisations experienced critical outages in 2024, including 123 incidents recorded across NHS England, while 28% of red-rated legacy systems lacked remediation funding. These facts make migration a governance concern, not just an infrastructure task.

Practical rule: A migration plan isn't ready when the transfer script works. It's ready when business owners can explain how they'll detect an incorrect result and recover without guessing.

The board-level question is therefore not, “Can the data be copied?” It's, “Can the organisation continue operating if the copy is incomplete, delayed or rejected?” That question determines the architecture, testing depth, cutover model and support arrangements.

Migration Types and the Mixed Environment Challenge

A platform move becomes risky when teams treat it as database copying. The actual work is preserving processes, permissions, reporting and service availability across systems that may change at different speeds. The migration type determines which dependencies must be tested and which failures the business can tolerate.

Storage migration transfers documents, media, archives or backups between file systems, data centres and cloud storage. Unsupported formats, altered permissions, missing metadata and underestimated volumes can make a technically successful transfer unusable. Database migration introduces schema incompatibility, transformation rules, referential integrity and transaction-consistency risks. Application migration also requires dependency mapping, configuration changes, identity integration and user acceptance. A new hosting location does not resolve those dependencies.

Cloud migration follows several routes:

• Rehosting: Move workloads with limited modification. This can shorten the change window, but it may retain inefficient architecture and unresolved technical debt.
• Replatforming: Adapt the workload for a managed database, new storage layer or revised runtime. Maintainability may improve, although compatibility testing becomes more demanding.
• Rearchitecting: Redesign the application around a different operating model. This may create a stronger long-term platform, while introducing the greatest change and coordination risk.
• Hybrid migration: Keep some systems on premises while moving other workloads to public or private cloud. This can support continuity, but it creates continuing integration, identity and monitoring obligations.

Mixed environments are the norm. Among businesses using digitised data, 31% used public-cloud providers, 27% used servers on their own premises, 19% used private-cloud providers and 22% used third-party software or web solutions, according to the UK Business Data Survey 2026. The survey also found that 29% stored and processed data only in external data centres, while 14% did so only in enterprise data centres.

Those figures translate into practical dependencies. A company may move its core database to public cloud, retain a warehouse system on premises, run its CRM through a hosted supplier and send operational telemetry elsewhere. Each connection needs mapped fields, compatible formats, controlled access, monitoring and a defined recovery path. It also needs an owner who can decide whether a failed interface stops the cutover.

Arch's guide to system integration and connected platforms provides a useful primer for this integration layer. The issue is not only where data is stored, but how applications exchange it, how quickly changes propagate and which supplier controls each hand-off.

Cloud adoption varies by organisation size. 60% of large businesses used public-cloud providers, compared with 35% of small businesses, 32% of microbusinesses and 30% of sole traders, as reported in the same survey. Smaller teams may have less redundancy and fewer people to validate records. Larger organisations face more suppliers, business units and regulatory boundaries. In both cases, operational ownership matters as much as the target architecture.

The End to End Migration Process and Timelines

A platform move succeeds when operations continue, not when a database import reaches 100%. Before extracting production data, establish what each system contains, how records are structured and whether the receiving environment can support the required formats. The National Archives recommends checking system versions, information architecture, file formats, information volumes and whether relevant software or hardware licences can transfer with the records. It also advises taking a backup and excluding redundant or duplicate information, as set out in its guidance on transferring digital records.

Discovery establishes the boundary

Build an inventory of systems, datasets, owners, interfaces, formats, retention rules and user groups. Record active data, duplicates and informal processes that staff now rely on. A spreadsheet may start the exercise, but the working inventory should become a controlled record with named owners who review and approve it.

Capacity planning must account for attachments, audit histories, exports, temporary files and backups. Agree which data will move, which will be archived, which can be deleted under an approved policy and which must remain available during transition. These decisions affect storage, validation effort, legal exposure and the length of the coexistence period.

The overall approach matters as much as the individual steps. Arch's guide to data migration strategies compares patterns that can help teams choose an approach based on operational constraints rather than preference.

Design converts knowledge into rules

Map source fields to target fields and document every transformation. Define how the target will handle missing values, duplicate identities, invalid dates, retired codes and records without a direct equivalent. These rules should be testable and approved by business owners, particularly where a transformation changes reporting, customer history or user access.

Choose between a one-time batch, incremental replication, staged loading or parallel operation. The decision depends on transaction volume, acceptable downtime, source-system capabilities and the organisation's ability to reconcile changes. A batch can reduce complexity but may require a longer freeze. Replication limits the freeze but introduces synchronisation and conflict risks.

For teams replacing specialised or heavily customised platforms, practical reading on modernising church extension fund systems provides context on legacy dependencies and controlled replacement. The same issue appears across sectors. Undocumented rules in the old system often create more risk than the destination database itself.

Testing proves more than technical transfer

A dry run should measure record counts, rejected rows, transformed values, permissions, relationships, search behaviour and business workflows. Test users should perform realistic tasks, such as creating an order, resolving a support case, generating a report and exporting a customer record. Include failure scenarios, including interrupted loads, unavailable interfaces and incomplete source data.

Reconciliation needs defined tolerances and named approvers. A completed import is not an acceptance criterion. The organisation should know which discrepancies are acceptable, which require correction and who can approve cutover.

Cutover and handover protect the result

The final runbook should set out freeze rules, communications, escalation contacts, validation checks, rollback triggers and a support rota. Rollback must work in operational conditions. If users create transactions after the final extract, the team needs a method to preserve and reapply them, rather than restoring an outdated snapshot and losing new activity.

Public-sector and archival projects require a longer horizon. The National Archives describes a 20-year rule for selected, sensitivity-reviewed digital public records transferred under the Public Records Act. The process covers appraisal and selection, sensitivity review, preparation, transfer through the Digital Records Transfer service and publication on Discovery. Its digital records transfer workflow can inform retention and handover decisions where records may later require public preservation.

Older files need a separate format workstream. The National Archives warns that software obsolescence can make files inaccessible and identifies format migration as one response, while advising organisations to retain original content after conversion. Its preservation workflow references more than 1,300 digital file formats in PRONOM and describes DROID as a tool for identifying formats through extensions or internal signatures in its digital-preservation workflow guidance.

Set the timeline from evidence. Discovery may be short for a controlled estate and extensive for a fragmented one. A schedule that excludes inventory, mapping, dry runs and business validation is incomplete, regardless of its technical ambition.

Security Compliance and Hidden Data Sovereignty Risks

Choosing a UK data centre doesn't automatically solve UK compliance. Data sovereignty is a mapping problem, because personal data can travel through services that aren't visible in the primary application architecture.

The ICO expects organisations to apply technical and organisational measures proportionate to processing risk. Its security guidance requires consideration of the recipient's controls, information sensitivity, system differences and operating procedures, as explained in the ICO security guidance for data sharing.

A migration control set should include:

• Data inventory: Identify personal data, special-category data, credentials, identifiers and operational records.
• Field-level classification: Apply handling rules to fields rather than treating an entire database as one risk category.
• Least privilege: Give migration staff and suppliers only the access required for their approved tasks.
• Encryption: Protect data in transit and at rest, with controlled key management.
• Immutable audit logs: Record who accessed, transformed, moved and approved data.
• Reconciliation: Compare counts, mandatory fields, relationships, permissions and deletion rules between source and target.
• Rollback: Define how the organisation will stop, reverse or contain a failed transfer.

A Data Protection Impact Assessment is especially useful when migration introduces a new processing system or materially changes data flows. For practical governance, convert DPIA findings into acceptance criteria. Production cutover shouldn't proceed until the project can demonstrate that access rights, retention rules and deletion behaviour work as intended.

The hidden transfer is often outside the database

Map every place where data is stored, processed or accessed. That includes backups, disaster-recovery replicas, staging buckets, monitoring logs, ticket attachments, analytics tools, support sessions and supplier subprocessors.

UK government procurement guidance explains that UK GDPR Article 44 restricts transfers of personal data outside the UK unless a valid legal gateway exists, such as an adequacy decision, the UK International Data Transfer Agreement, binding corporate rules or another recognised mechanism. The guidance also covers UK to EU and EEA flows under the applicable adequacy arrangement. Use the UK government guidance on data protection legislation to review the legal basis and safeguards for every destination.

A cloud service can appear UK-hosted while its support team, failover region or observability provider operates elsewhere. The migration runbook should therefore record physical and logical processing locations, access countries, processor responsibilities, contractual instructions and incident obligations.

A 2025 survey of 450 UK and Irish SMEs found that 61% of UK SMEs were anxious about where their data was stored, while 30% were undecided about switching hosting providers and 42% had no plans to do so, according to the context supplied by ICO guidance on restricted transfers. The figures point to a practical governance gap. Organisations need to ask, after migration, who can access the data, from which country, for what purpose and under which safeguard.

Maintaining Business Continuity During Cutover

A migration can meet every technical acceptance criterion and still damage revenue. An online retailer may lose order visibility, a transport operator may be unable to retrieve delivery information, or a service business may show support staff incomplete customer histories. The platform remains available, but the operation no longer works for customers.

UK evidence shows why cutover deserves board-level attention. 79% said migration projects were inconvenient and disruptive because they affected core IT systems, while 72% across sectors found it difficult to stop continuously used IT operations, according to IT Pro's coverage of data migration disruption. The publication was updated in April 2025, although the underlying evidence is older.

A shorter cutover window is not automatically safer. Reducing the volume of change at each stage can lower operational risk, even when the overall programme takes longer.

Design for continued trading

Begin with a business continuity workshop rather than a technical scheduling meeting. Department leads should identify the workflows that must continue, the minimum acceptable service level and the conditions that require the migration to stop.

Define these measures before the first production transfer:

• Maximum tolerable downtime: The longest interruption each critical service can withstand.
• Recovery-point objective: The amount of recent activity the business can afford to recreate after a rollback.
• Reconciliation accuracy: The checks required before users can rely on the target system.
• Departmental acceptance: Named users complete real tasks, rather than approving screens or database counts alone.
• Rollback trigger: A measurable condition that stops cutover without a late argument.

Phased migration can move lower-risk teams, records or workloads first. Parallel operation preserves access to the old system while the new platform proves itself, but it creates synchronisation, reconciliation and support overhead. Running both systems is a deliberate trade-off, not free protection. Assign an owner, define the controls and set the end date before parallel operation begins.

Rehearse the uncomfortable scenario

A dry run should include delayed transfers, failed validations, duplicate updates and unavailable dependencies. Ask the team to execute the rollback runbook without the person who wrote it. That exposes unclear steps, missing permissions and decisions that exist only in someone's memory.

The UK Business Data Survey also provides a useful reminder that outages affecting business activity remain an operational concern. Use that context to test whether the proposed fallback protects orders, customer records, finance processes and field operations, rather than merely restoring servers.

Continuity is demonstrated by business users completing their work, not by infrastructure dashboards turning green. Before approval, the board should see evidence that critical operations can continue during transfer and that rollback has been rehearsed under realistic conditions.

Vendor Selection and Migration Maturity

The cheapest migration proposal often excludes the work that prevents expensive failure. Vendors that price only extraction, transformation and loading may leave the client responsible for discovery, data ownership, process testing, compliance mapping and post-cutover support.

Compare partners across delivery method, not just technology logos.

Look for operational maturity

Ask how the provider will:

• Discover unknowns: Request system inventories, dependency maps, data owners and examples of undocumented workflows.
• Handle bad data: Explain duplicate detection, validation, rejected-record queues and exception ownership.
• Protect production: Describe replication, throttling, access controls, encryption, audit trails and rollback.
• Prove readiness: Show how test runs, reconciliation and user acceptance become formal gates.
• Support handover: Define monitoring, incident response, documentation and ownership after go-live.
• Manage suppliers: Identify how cloud providers, SaaS platforms and subprocessors fit into the risk model.

A technically capable partner may still be a poor fit if it can't communicate with finance, operations, legal and customer-service stakeholders. Conversely, a consultancy with strong process discipline may need specialist support for an unusual database engine or file format.

Match the partner to internal capacity

An experienced internal team may need targeted engineering and independent assurance. A smaller organisation may need a partner to provide discovery, delivery management, testing coordination and support. Neither should outsource accountability. The business still owns lawful processing, retention decisions, service priorities and acceptance.

A useful guide to choosing a data migration partner can structure supplier questions before procurement begins. Request a sample runbook, an example reconciliation report and a clear description of what happens when the source and target disagree.

Arch offers data migration within its web-hosting services, alongside data replication, data security and encryption. It also supports data importing and exporting across formats including CSV, ODF, PDF, MySQL and ZIP. Treat those capabilities as part of a wider evaluation that includes discovery, continuity planning, governance and long-term support.

The strongest partner will discuss what it won't move, what it can't validate automatically and what the organisation must decide before delivery starts. That candour is more valuable than a smooth demonstration.

Frequently Asked Questions

What should happen to obsolete file formats during migration?

First identify formats through extensions and internal signatures, then test whether the target platform can preserve the original content and required metadata. If conversion is necessary, retain the original alongside the converted version, document the tool and transformation, and validate representative files after transfer. The National Archives' preservation guidance explains why technology obsolescence creates accessibility risk and why original content should be retained after format migration.

What drives the cost of data migration services?

Cost is usually driven by discovery effort, data quality, system heterogeneity, transformation complexity, testing depth, continuity requirements and post-cutover support. A clean database with a stable schema may need limited transformation, while a mixed estate can require extensive reconciliation, identity mapping and staged operation. Ask vendors to separate fixed activities from uncertainty allowances, then price exception handling rather than assuming every record will migrate cleanly.

What changes when migrating public records?

Public-record projects need appraisal, selection, sensitivity review, preparation, controlled transfer and publication planning, not just a technical export. The National Archives describes a 20-year rule for selected digital public records under the Public Records Act. Confirm retention ownership, metadata requirements, access restrictions and the eventual handover route before designing the target structure, because later archival obligations may influence what information must be preserved during migration.

About the Author

Hamish Kerry is the Marketing Manager at Arch, where he's spent the past six years shaping how digital products are positioned, launched, and understood. With over eight years in the tech industry, Hamish brings a deep understanding of accessible design and user-centred development, always with a focus on delivering real impact to end users. His interests span AI, app and web development, and the potential of emerging technologies. When he's not strategising the next big campaign, he's keeping a close eye on how tech can drive meaningful change.

Hamish's LinkedIn: https://www.linkedin.com/in/hamish-kerry/

Meta description: Data migration services explained, with UK compliance, sovereignty risks and practical business continuity guidance.

Arch helps organisations plan and deliver secure digital platform moves, including discovery, data migration, hosting, support and solid engineering. Visit Arch to discuss a migration approach that protects continuity while preparing your systems for long-term change.