Document system migration is most often presented as a technical project. In reality, it is a decision about how an organization will work with documents in three years, not only about how files will be transferred in twelve weeks.
This difference has a name: the TO-BE model. The decision whether we define it before the transfer or not is the most reliable predictor of whether the migration will be successful.
A TO-BE model is the definition of the target state of the document system, meaning how the organization wants to work with documents after migration. It includes document structure, classification, metadata, processes, roles and access rights, integrations, and compliance requirements. It defines the way of working, not technical specifications.
TO-BE Is Not a Technical Specification
The TO-BE model is often misunderstood as a document prepared by the technical team: a list of functionalities, a data model, an architectural diagram. This is only a smaller part of the picture.
The TO-BE model is the definition of the future way of working with documents. It determines how documents will be created, who will work with them, how they will be connected to processes, and how the organization will control them. Technology is the consequence of these decisions, not their starting point.
If an organization prepares the TO-BE model at the level of specification, it gets a system that meets requirements. If it prepares the TO-BE model at the level of the way of working, it gets a system that users actually use. This is not the same thing.
The TO-BE model describes the target state, how we want to work after migration. The AS-IS analysis describes the existing state, meaning how we work today. TO-BE is defined first, because without a target framework, the AS-IS analysis remains only an inventory of the current state, not a basis for decisions about what to transfer, what to redesign, and what to abandon.
6 Questions That Define the TO-BE Model
In practice, the TO-BE model means that before the start of migration we must clearly define six dimensions. Each question determines how the new system will work in everyday use. Each skipped question is a risk that will appear after go-live, not before it.
When do we define the TO-BE model in the project? We define the TO-BE model at the very beginning of the migration project, before the AS-IS analysis and before any data transfer. In practice, this is the first phase of migration and a condition for all further steps.
1. What Will the Document Structure Look Like?
Classification, cases, folders: how documents will be organized in the new system. This is not an IT question, but an organizational question. Classification must reflect the actual way of working, not historical structures that have accumulated over the last 10 or 20 years.
In practice, this is where the first mistake appears: organizations often transfer the existing structure because it is "known". But known is not the same as functional.
2. Which Metadata Will Be Mandatory and How Will It Be Added?
Metadata is the foundation of search, filtering, automation, and reporting. Without consistent metadata, a document system becomes a large file server.
The key question is not only which metadata will be mandatory, but also how it will be added. Manually? Automatically from connected systems? With OCR or AI classification? This decision determines whether standardization will work in practice or remain on paper.
3. How Will Documents Be Connected to Business Processes?
Workflow and BPM are not an addition to the document system, but one of its essential functions. Documents that are not connected to processes are just files. Documents that support processes are part of business logic.
In the TO-BE model, we must define which processes run through the document system, how they are triggered, who approves them, and how they are completed. This is also the moment to ask whether existing processes even make sense, or whether they are a remnant of the previous organization.
4. What Will User Roles and Access Rights Look Like?
Who sees what, when, and why must be clearly defined from the beginning. Access rights that accumulated organically in the old system are one of the biggest sources of risk: users have access they no longer need or never needed, but it is technically difficult to remove it.
The TO-BE model is an opportunity to redefine roles based on actual responsibilities, not history.
5. How Will the Document System Connect with Other Systems?
Integrations with ERP, HRM, CRM, and IAM are not an optional addition, but a condition for usability.
Documents are created in other systems, refer to their data, and often trigger processes in them.
In the TO-BE model, we must define which integrations are critical, which are meaningful, and which can wait. Without this, ad hoc decisions are often made during implementation, which later become technical debt.
6. How Will Compliance, Security, and E-Archiving Be Ensured?
Regulatory requirements must be part of the design, not a later correction. Retention periods, document immutability, time stamping, audit trail. All of this must be defined before migration, not arranged after it.
Compliance established after the transfer is always more expensive and less reliable than compliance built into the design.
The TO-BE model is not the task of one person or one team. It is shaped together by business users who work with documents every day, process owners, representatives of compliance, and technical teams. Management defines priorities and gives the mandate. A migration defined only by IT is technically correct, but rarely successful from a business perspective.
Let's Transfer Everything, and Then We'll Organize It
This is the sentence we most often hear in practice. At the same time, it is the best predictor that the result will not meet expectations. With this sentence, the organization has a good intention to organize documents. It understands that organization is necessary, but postpones it until after the transfer because it seems that it will be easier then.
In practice, this almost never happens. There are several reasons:
After migration, there is no more project energy.
Migration is an intensive project with a clear goal and deadlines. When the transfer is completed, the organization returns to regular business. The task "let's organize the documents" loses priority because it competes with everyday work.
After migration, there is no more mandate.
During migration, everyone is prepared to make decisions about classification, roles, and rights. After the transfer, this readiness disappears: each department returns to its own priorities, decisions become time-consuming and political.
After migration, habits are already established.
Users who work for two months with an incomplete structure begin to perceive it as given. Every later reorganization is a change to their habit, not the introduction of something new. Psychologically, this is significantly harder.
The result is a system that, two years after migration, works in a way that nobody planned, but everyone has become used to. Technically it is new, but in content it is the heir to everything that should have been left behind.
The organization transfers the existing state into the new system, including disorganized structures, inconsistent metadata, and outdated access rights. The consequences appear after go-live: low system adoption among users, loss of traceability, loss of connections between documents and processes, compliance issues, and underuse of the new system's capabilities. The migration is technically completed, but from a business perspective, it rarely justifies the investment.
Migration as the Opportunity for Organization
In everyday business, there is no time for a thorough reorganization of classification, standardization of metadata, or review of access rights. These activities always fall to the end of the priority list. Migration, however, is the moment when all of this becomes necessary because a new system is being prepared.
If we do not use this moment, the next opportunity for such a review comes only with the next migration, which is usually in 5 to 10 years.
Every document system migration is ultimately an answer to one question: what kind of way of working with documents does the organization want to have in three years? When the answer is clear, everything else becomes a consequence of that one decision. When the answer is not clear, everything else becomes improvisation.
For a comprehensive overview of all aspects of migration, see: