When an organisation replaces a system, consolidates platforms, or shuts down an older solution, a question about the documents almost always arises: How do we get them into the new system?

If you have not previously worked with document migration, the task may sound relatively straightforward. The files simply need to be moved from one system to another. But that understanding only holds as long as documents are regarded as ordinary files. In practice, documents in organisations are almost always more than that.

For many documents – and especially for those we consider records – the value does not lie solely in the content of the file. The value also lies in the documented context: who created the document, when it was approved, which case or process it belongs to, and which version is the valid one. When such documents are moved from one system to another, the task is therefore not simply about moving files. It is about preserving evidence.

Documents Are Not Just Files

A document in a document management system typically consists of several elements. There is the content file itself – for example a Word document or a PDF. But there is also metadata describing the document, as well as relationships to other documents or objects in the system.

Metadata can be relatively simple information such as title or document type. But in many cases metadata also contains information that is crucial for the meaning and credibility of the document. This may include approval information, version history, or its relation to a particular case, product or process.

Documents are also often part of structures and contexts. A document may be one version within a version chain, part of a case file, an attachment to another document, or part of a larger documentation set. These relationships help define the document’s context.

When documents are moved from one system to another, this context must follow them. Otherwise the documents may exist in the new system but without the connections that make them understandable and trustworthy.

Records Require Preserved Context

The difference between data and records becomes particularly clear in this context.

Structured data can often be moved relatively mechanically from one database to another. Fields can be mapped to new fields, and values can be transformed according to relatively clear rules.

Documents and records behave differently. Here, metadata is not merely a technical attribute but part of the document’s evidential value. If, after migration, it is no longer possible to see who approved a document, when it was approved, or which version was valid at a given point in time, the value of the document as evidence is significantly reduced.

In some organisations this may primarily be a matter of internal trust in the documentation. In others – particularly in regulated environments – it can have more formal consequences. Here documentation may form part of the evidence underlying regulatory approvals, quality management systems or traceability requirements.

This does not mean that all documents require the same level of control during migration. But when documents function as records, the migration must be designed with the objective of preserving their integrity and context.

When Documents Leave Their System

A significant challenge in migration arises at the moment documents leave the system in which they were originally created and managed.

In the original system, the structure, metadata and relationships of documents are typically managed by the system’s own logic. The system knows how versions relate to each other, how documents connect to cases or processes, and which metadata fields are mandatory. Not least, the content file itself is protected.

When documents are exported, this system logic temporarily ceases to protect them. The documents exist for a period outside their original context. It is during this phase that the risk arises that metadata may be lost, relationships broken, values altered unintentionally – and the content file may become corrupted either through technical error or through malicious interference.

The migration task therefore consists of establishing a controlled process in which the documents – meaning both the content file and the metadata, as well as the relationship between them – remain under full control during their transition from the source system to the receiving system.

This may involve transforming metadata if the new system organises information differently from the old one. But such transformations must be consistent, documented and controlled so that it is possible afterwards to explain and demonstrate how the documents were handled during the migration.

Relationships Must Be Re-Established

Another challenge arises from the relationships between documents.

Documents rarely exist in isolation. There may be multiple versions of the same document, different renditions (for example in different file formats), or relationships to other documents within a case or process.

If such relationships are not handled correctly during migration, the result may be that documents lose their connections to each other. Version trees may be broken, attachments may become detached from their parent documents, and documents may end up without the context that explains their role.

A migration therefore often requires a carefully planned sequence for loading documents into the new system. Original versions must be created before subsequent versions, and related objects must exist in the system before relationships between them can be established.

It is precisely considerations like these that make document migration a discipline in its own right and distinguish it from the migration of structured data.

The Real Purpose of Migration

Viewed from the outside, migration can appear to be a technical exercise: export from one system, import into another.

But if the documents have value as documentation – as records – the purpose is different. The purpose is to ensure that after migration the documents can still be used as trustworthy evidence of what they represent.

This means that it is not enough simply to be able to find the document in the new system. One must also be able to understand its context and trust that it is the same document that previously formed part of the organisation’s processes.

Migration therefore becomes not merely the movement of files, but a controlled transfer of documentation.

Conclusion

In some situations it may be entirely sufficient to copy files from one system to another. If the documents have no particular documentary significance and their metadata does not play an important role, a simple file transfer may be a practical solution.

But when documents function as records, the task changes in nature. It is no longer enough to move the content file alone. Metadata, relationships and the context that make the document trustworthy documentation must also be preserved.

This is why we speak of document migration, not simply file transfer. The real task of migration is not to move documents from one system to another, but to ensure that the evidence contained within them survives the system change.

When Compliance Is Reduced to Documentation

When organisations establish a compliance or governance framework, the work almost always begins with documentation. Policies must be formulated, procedures described, and responsibilities and workflows clarified. This is a necessary and important part of creating a shared foundation for governance.

Once policies have been written, procedures published, documents placed in a system, and relevant employees informed and trained, the implementation phase is largely complete. The organisation has articulated its rules and made them accessible.

But documentation is only the starting point. Regulatory requirements ultimately do not focus on the documents themselves, but on the organisation’s actual actions – and on the ability to demonstrate that these actions have been carried out in a controlled manner.

There is therefore an important distinction between documentation and documented behaviour. Documents can describe how something should be done. Compliance only emerges when the organisation’s actions follow the established guidelines and when those actions leave traceable evidence.

Documents establish the framework. Evidence only arises through the actions and records that demonstrate that the guidelines have actually been followed in practice.

When Governance Shifts from Documents to Actions

Once the foundational documentation has been established, the real work begins. The focus shifts from describing the rules to ensuring that they are followed in practice.

At this stage, it becomes clear that compliance is not primarily demonstrated through policies and procedures, but through the traces left behind by the organisation’s actions. These may include records of approvals, changes in systems, access assignments, or the handling of incidents.

A change control procedure does not in itself create control over changes. A policy on access management does not in itself ensure correct access. And an incident management procedure does not in itself handle a security incident.

Documents describe the expected behaviour. Compliance can only be demonstrated when the organisation’s systems and processes support that behaviour in practice – and when they simultaneously record what was done, by whom and when.

It is within this recorded behaviour that the true evidence of compliance emerges.

Documents Describe – Systems Document

If compliance is not primarily about documents, what is it about? It is about documented control.

In this context, control means that the organisation performs specific actions under defined conditions as part of its processes. The term is used here in the professional sense of a control mechanism – not in the everyday sense of checking something (or someone). Documented control means that these actions can be demonstrated afterwards.

Documents still play an important role in this context, but in a different way than often assumed. They describe the controls and define the framework for the work. The evidence itself arises from the records of the actions that are carried out.

When a manager approves a document in a system, the evidence is therefore not the document itself. The evidence is the record of the approval: who approved it, when it was approved, and which version was approved. Similarly, in change management it is not the procedure that documents compliance, but the history of assessments, decisions and implemented changes.

Documents establish the framework for behaviour. Evidence arises in the traceable records showing that controls have actually been performed.

Controls in Practice

When looking at organisational control environments, this principle becomes visible in a number of familiar mechanisms.

Approvals are an obvious example. When a contract, report or change is approved, the system typically records who approved it, the time of approval and which version was approved. These records constitute traceable evidence.

The same applies to change control. When changes are registered, assessed and implemented through a controlled process, a history of decisions and actions emerges that makes it possible to demonstrate afterwards how the change was handled.

Access management and incident management function in much the same way. Compliance is not documented through the access policy or the incident management procedure, but through the records showing who received access, which incidents occurred, and how they were handled.

The common characteristic is that evidence arises through the recording of actions.

The Role of Systems

When compliance is understood as documented behaviour, the role of systems becomes central.

Digital systems make it possible to record actions consistently and uniformly. They can ensure that approvals are recorded with identity and timestamp, that changes are not implemented without a documented decision, and that history is preserved through audit trails.

In this way, systems become the framework within which the organisation’s controls are both performed and documented. It is this traceability that makes it possible to review afterwards what has taken place.

Compliance therefore does not arise in the document repository alone, but in the interaction between documents, systems and the actions performed by the organisation’s employees.

From Document Management to Documented Control

Document management is an important discipline because it ensures that the organisation’s policies, procedures and instructions are clear, accessible and version controlled.

But compliance is ultimately not assessed based on the structure of documents. It is assessed based on whether the organisation’s controls are actually performed – and whether they can be demonstrated.

It is therefore documented behaviour that forms the core of a well-functioning control environment. Documents describe how the work should be carried out. Systems and processes create the evidence that it actually happens.