ECM Migration: The moment you inherit everyone’s mess

In my last blog post, I wrote about the importance of ownership of information.

Today, I would like to consider what it means when we decide to start a migration project.

We have 2 million documents in our current ECM. We need to migrate them to the new platform.

It sounds simple.

At least, it does when you put it in a project plan:

• Extract the documents
• Transform the metadata
• Load everything into the new system
• Validate the result
• Go live

Then you start looking at the contents of those 2 million documents and the questions begin:

• Which documents are still relevant?
• Which ones are duplicates?
• Which ones are obsolete?
• Which ones are legally required to be retained?
• Which ones are just old drafts?
• Who owns them?
• Are the permissions still correct?
• Is the metadata meaningful?
• Does anyone even know why some of these documents exist?

Suddenly, migration doesn’t look like a technical project anymore.

It looks more like an archaeological excavation!

And that is the uncomfortable reality about ECM migrations:

Migration is the moment when you inherit everyone’s mess.

Migration doesn’t create the mess

One of the biggest misconceptions about ECM migration is that the migration project is responsible for creating the information problems.

This is usually not the case. These problems have been accumulating for years:

• A document was created for a project.
• Someone copied it to another folder.
• Another person downloaded it and changed the file name.
• A new version was uploaded elsewhere.
• The project ended.
• The people involved moved to other departments.
• The folder structure changed.
• The retention rules changed.
• The application that created the document was replaced.
• Nobody went back to clean up what was left behind.
• Multiply this by thousands of users and years of activity, and the result is what I call ‘information debt’.

This debt isn’t visible on a daily basis; people simply work around it. Day after day, searching for information takes longer and longer.
They create this mess through the way they work: keeping several copies of documents, asking colleagues where things are, creating additional folders and saving documents ‘just in case’.

Until one day, someone says: “We’re migrating to a new ECM.”

Suddenly, all that accumulated debt becomes part of the migration scope. This is why migration projects often reveal problems that have existed for years. Migration does not create the mess. It simply makes the mess impossible to ignore.

The “just migrate everything” strategy

When faced with a large repository, it is understandable to have a certain reaction.

“We should migrate everything. We don’t want to lose anything.”

This approach sounds safe and responsible.

And sometimes it is also the easiest political option, because nobody has to make difficult decisions, explain why 15-year-old documents were deleted, or decide whether old project folders still have value.

You just move everything, But the problem is that you haven’t solved the information problem.

You’ve just moved it!

It’s like moving house: your old basement is full of boxes.

Rather than opening the boxes and deciding what you need, you simply load them onto the truck and store them in the new basement.

Technically, the move was successful. But you haven’t tidied up at all.
Ultimately, you continue to have years of old stuff that your family doesn’t need, but now it’s in a new building.

That’s exactly what happens with many ECM migrations.

Old repository → migration → new repository.

A few months later: “Why is the new ECM already so difficult to navigate?”

Because you migrated the old information environment instead of redesigning it.

The three questions

Before deciding how to migrate content, I think every organization should ask three simple questions:

• Should we migrate it?
• Should we keep it somewhere else?
• Or should we delete it?

Although these questions may sound obvious, they are surprisingly difficult in practice.

Migrate it

Clearly, some information is still valuable.

For example:

• active contracts;
• current customer documentation;
• ongoing projects;
• current procedures;
• active employee records;
• current policies;
• documents actively used by business processes;
• information required for day-to-day operations.

This content is suited to the new information environment. Ideally, it should not simply be copied as it is.

The migration provides an opportunity to improve the classification, metadata, relationships and lifecycle of the content.

The objective is not just to put this document into the new system, but to ensure that this information is useful within it.

These are very different objectives.

Archive it

The second category is more subtle.

While some information still needs to exist, it doesn’t need to remain part of the active working environment.

Consider:

• closed projects
• expired contracts
• historical financial records
• old customer files
• completed cases.
• previous versions that must be retained
• records subject to regulatory retention

These documents may have little operational value today.

However, this does not necessarily mean that they can be deleted.

Organizations often confuse two very different concepts here. Keeping something is not the same as actively using it.

Retention requirements may mean that information must remain available for several years.

However, this does not automatically mean that it belongs alongside the documents that people use every day.

Archiving can therefore be an important part of a migration strategy.

The aim is not to ignore historical information. Rather, the goal is to prevent historical information from overwhelming current information.

Delete it

Then comes the most uncomfortable option. Delete it.

Some information simply isn’t worth migrating.

• duplicates
• temporary exports
• old drafts
• test documents
• abandoned documents
• obsolete versions
• documents created for a one-off purpose that no longer exists
• files with no business value or retention requirement
• documents that nobody can explain

This is where migration projects can become political.

Someone will inevitably say: “We might need it someday.”

Maybe! However, “we might need it someday” is not an information management strategy.

If every document is considered potentially useful forever, nothing can ever be deleted.

If nothing can ever be deleted, your information environment will eventually resemble a historical archive rather than a working system.

The fourth category: nobody knows

However, in (almost) every migration project, there will always be a category that doesn’t fit neatly into ‘migrate’, ‘archive’ or ‘delete’.

Nobody knows.

You find a document, it looks important.

But nobody knows:

• Who owns it?
• Whether it is still valid?
• Why it exists?
• Whether it is a record?
• Whether there is a newer version?
• Whether it can be deleted?

So, what do organizations usually do?

They migrate it, because migration feels safer than making a decision.

This creates what I call the “just in case” migration.

“Just in case” is one of the most expensive phrases in information management.

Unknown content should not automatically be migrated.

The right answer is often to investigate before migrating.

The hidden problem

As I have already mentioned, documents are only one aspect of the migration process.

The other part is the information surrounding those documents: metadata.

Legacy ECM systems often contain years of accumulated classifications, fields, document types, folders and custom properties.

Some of these are useful and some aren’t. Sometimes they were created for a specific department, others were created because the old system required them.

Some have values such as:

• Other
• Miscellaneous
• Unknown
• N/A
• Old
• New
• Final
• Final_final

Then, as with documents, there are fields that nobody remembers either.

Yet during migration, there is often pressure to map everything.

• Old field → new field.
• Old document type → new document type.
• Old folder → new folder.
• Old classification → new classification.

This looks like the secure way to proceed. However, this can result in something worse than a bad legacy system.

A new system that incorporates a legacy model that has been successfully migrated.

Ultimately, no solution or improvement has been offered, the new ECM has the same issues as the previous one.

Do not migrate the structure, migrate the meaning

This is one of the most important lessons I have learned from working with various ECM environments.

A migration does not necessarily have to reproduce the inherited structure.

The important thing is to preserve the information.

Imagine a legacy repository containing: Customers / Switzerland / Active / Contracts / 2026

This folder tells you something, but it also tells you very little.

In a metadata-driven environment, the same document could be described using properties such as:

• Document class = Contract
• Customer = Customer X
• Country = Switzerland
• Status: Active
• Contract year: 2026

The document is not dependent on a particular folder structure.

It has context.

This context can be used for:

• Search
• Views
• Security.
• workflows.
• Reporting.
• Automation
• AI

This is one of the reasons I prefer working with a metadata-driven ECM solution such as M-Files.

However, there is an important warning here: M-Files won’t magically clean up your information.

Migrating bad information with bad metadata simply creates a better system for finding bad information.

The technology can support a better information model, but it cannot make decisions for you.

Migration is not a copy operation

I think it is important to distinguish between technical and information migration.

Technical migration asks: “Can we move the documents successfully?”

An information migration asks: “Are we moving the right information, with the right context, into the right structure?”

These are completely different questions.

It is possible to have a technically perfect migration and still have a terrible outcome.

Don’t forget the relationships

Another aspect that is often overlooked during migration is relationships.

Documents rarely exist in isolation, for example:

• A project document belongs to a project.
• An invoice belongs to a supplier, and potentially to a contract.
• An employee document belongs to an employee.

When migrating, we often focus on the document itself.

However, the more important question may be: “Did the context arrive with it?”

If not, you have migrated the document but lost part of its meaning.

This is particularly important when transitioning from folder-centric repositories to object and metadata-driven approaches.

The goal isn’t simply to preserve files, it’s to preserve information and context.

An opportunity to reduce information debt

This is probably the most important link to my previous article on information debt.

Information debt builds up when organizations repeatedly postpone decisions about their information.

Migration offers a rare opportunity to ask the right questions:

• What do we have?
• What do we need?
• Who owns it?
• How long should we keep it?
• What does it mean?
• How should it be classified?
• Who should have access?
• What can we get rid of?

These questions make migration painful.

But they also make migration valuable.

If you only use migration to move information, you miss the opportunity.

Instead, you can use it to reduce your information debt.

Do not migrate your history

Every ECM migration eventually raises an uncomfortable question:

Does this information still deserve to exist?

The goal shouldn’t be to recreate yesterday’s information environment using tomorrow’s technology. Rather, it should be to move the information that the organization still needs, retain what must be kept and remove what no longer has a reason to exist.

After all, technology can move millions of documents remarkably quickly. The real migration project is deciding which of those documents deserve to survive.

A successful migration isn’t about moving everything.

It’s about starting tomorrow with less information debt than you have today.

So, please stop asking: “How are we going to migrate everything?”

Ask a very different question: “What is actually worth taking with us?”

That’s where a successful ECM migration begins.