A migration from file servers to SharePoint or to a new file server initially sounds like a technical task: analyze data, copy, transfer permissions – done.
In practice, however, it quickly becomes clear that a successful migration is far more than a copy process. Historically grown data structures, unnecessary permissions, unknown dependencies, and thousands of file links make migration projects complex. Anyone who discovers these factors only during the actual migration risks rising costs, delays, and, in the worst case, interrupted business processes.
This is exactly where the concept of best-case migration comes in: A migration should be understood as an expert-led restructuring – not as a mere transfer of data.
In the webinar on September 24, 2026, Rüdiger Massih and Thomas Gomell showed why pure lift-and-shift migrations often lead to problems – and how file server and SharePoint migrations can be systematically prepared and safeguarded.
Webinar recording: The best-case migration for file servers and SharePoint
See in the recording how migRaven.MAX analyzes and cleans up data and permissions, involves data owners, makes dependencies visible, and safeguards migrations with readiness checks, central project control, and link repair – and how AI supports planning, decision-making, and execution in the process.
The real challenge is not "A to B"
File server and SharePoint migrations have one thing in common: In most companies, the existing structures have grown over years or decades.
This not only results in large volumes of data. Permissions, groups, identities, and dependencies also continue to evolve – often without the original structure still being fully documented.
This leads to several key challenges.
1. ROT data: Not everything needs to come along
A significant portion of the data on file servers consists of so-called ROT data: redundant, obsolete, and trivial data.
Based on experience from numerous migration projects, it often turns out in customer environments that a large part of the existing data is no longer productively needed. Identifying this data and deciding together with the responsible business units on deletion, archiving, or migration is therefore one of the most important steps before migration.
After all, anyone who migrates everything also migrates unnecessary data along with it. At the same time, this increases storage requirements, review effort, and the complexity of the target environment.
Especially with SharePoint, there is another aspect: The quality of the data basis also affects the later use of AI applications. Redundant, outdated, or incorrect content is not a good foundation for intelligent search and assistance functions.
The decisive question is therefore not only: How much data are we migrating? But also: Which data should actually be migrated?
2. Grown permissions quickly become a security and cost factor
Permission structures also grow over the years.
Obsolete user accounts, unnecessary groups, group nesting, and overprivileged accounts can result in nobody having a complete overview of who can actually access which data.
This is problematic for a migration – and also relevant from a security perspective.
A migration should therefore not simply carry existing problems over into the new environment. Rather, it offers the opportunity to analyze permission structures, remove obsolete rights, and create a comprehensible permissions concept for the target system.
Especially for a migration to SharePoint, a simple 1:1 transfer of the previous file server permissions is often not the right approach. Instead, the target structure must be deliberately planned.
3. File links: When the migration is technically successful, but the business comes to a standstill
A frequently underestimated risk is links within files.
Excel files, documents, and other files can reference numerous other files or paths. Such links can be critical for business processes – for example, for formulas, macros, or automated workflows.
If file paths change as a result of a migration, these connections can break.
This creates a scenario that was expressed particularly clearly in the webinar: The migration can be technically completed successfully on Sunday evening – and yet an important business process comes to a standstill on Monday.
This problem can hardly be solved reliably by manual means. In large environments, there can be a very large number of links.
This is why analyzing and, if necessary, repairing links is part of professional migration planning.
4. Dependencies must be made visible
Not every dependency is documented.
An application may access certain directories, a service account may require permissions, or a business process may depend on files at a specific storage location.
These very dependencies are critical, because they can be unnoticeably interrupted by a migration.
A simple email inquiry along the lines of "Which paths does your department use?" typically does not provide a complete picture of actual usage, based on experience. It therefore makes sense to record access already before the migration and to observe it over a longer period.
5. Data owners: IT cannot make every business decision
Another key role in the migration project is played by the data owners.
IT can analyze which data exists, which permissions are in place, and which technical dependencies exist. However, it cannot decide for every file, from a business perspective, whether its content is still needed.
These decisions must be made where the business knowledge resides.
Data owners therefore take on a central role: for example, they decide which data is migrated, archived, or deleted, which target structure is used, and who needs access in the target system.
The problem: in many companies, it is initially unclear who is responsible for which directory.
Identifying and involving data owners is therefore itself an important part of project preparation.
The path to a best-case migration
How can a structured approach be developed from these challenges?
The webinar presented a step-by-step solution plan for this.
Step 1: Make visible, analyze, and understand
At the beginning is the analysis of the existing environment.
This includes, for example:
- Data volumes and data age
- File types
- Directory structures
- Permissions
- responsibilities
- Data owners
- Dependencies
- Potential ROT data
- Technical limitations
Only once this information is available can a meaningful decision be made about what should actually be migrated.
An example from a large migration project shows how far-reaching such decisions can be: when preparing a SharePoint migration, a rule was established according to which data older than seven years was deleted before migration or, if retention obligations existed, archived. This significantly reduced the volume of data to be migrated.
Step 2: Clarify dependencies and permissions
Dependencies and permissions should be examined in parallel with data analysis.
Which applications access which directories? Which service accounts are involved? Which permissions are actually needed?
Continuous auditing can help make actual access visible and provide a solid information basis for the business discussions with data owners.
Step 3: Central Clean-up
Before business departments begin the actual migration, IT should already carry out a central Clean-up.
This can include, for example, obsolete permissions or groups that are no longer needed.
A typical example: an employee was granted explicit rights to a folder several years ago for a one-time business process. Since then, no work has been done there, and she no longer needs this access. Such outdated permissions can be removed before migration.
This reduces the number of permission decisions that later need to be clarified together with the business departments – and makes the entire project leaner.
Step 4: Prepare target system and processes
In parallel, the target system is prepared.
Depending on the scenario, SharePoint sites, Teams, or file server structures can be prepared, for example. Self-service processes can also be established, allowing data owners to manage certain directories themselves or create corresponding structures.
The key point: the target system should not be created only once the first data has already been migrated.
Step 5: Guide business departments specifically through the migration
Only now does the actual business migration come into focus.
The relevant directories are assigned to the responsible data owners. They decide on Clean-up, target, and permissions.
At the same time, auditing remains active in order to track actual access and dependencies during preparation and migration as well.
This turns a technically driven migration into a structured process between IT, project management, and business departments.
Migration to SharePoint: readiness instead of surprises
Especially when migrating to SharePoint, technical requirements must be taken into account at an early stage.
This includes, among other things, file types, data age, data volumes, and path lengths. Defined migration policies can be used to specify which requirements a directory must meet before it can even be migrated.
This can, for example, prevent incompatible file types or undesirably old data from entering the target environment.
A readiness check thus provides a clear answer to the question: Is this directory actually ready for migration?
If not, the data owner can specifically identify what still needs to be done.
Path lengths can also be taken into account here. The webinar explained that, depending on the access scenario, different technical limits are relevant and the readiness policy can provide corresponding notices. Names are not automatically shortened; instead, problematic structures can be specifically identified and adjusted from a business perspective.
Centrally controlling and monitoring migration
In larger projects, it is not enough to start individual copy jobs.
Project managers need an overview of the entire scope:
- Which directories belong to the project?
- Who is the data owner?
- Which readiness checks have been passed?
- Which directories are blocked?
- Which migration wave is planned?
- Which jobs are currently running?
- Which data has already been transferred?
- Was the migration successful?
Central project control and migration monitoring create transparency here. Communication with data owners can also be integrated directly into the process.
AI as support for migration and decision-making
Another focus of the webinar was the use of AI.
The foundation is a so-called knowledge graph, in which information from different systems can be linked together. This includes, for example, file servers and Active Directory as well as Microsoft 365 services such as OneDrive, SharePoint, Exchange, Teams, and Entra ID. Third-party systems can also be connected via APIs.
The advantage of this approach is that questions are not answered based on individual data sources alone. The AI can use information from the actual context of the infrastructure.
This can, for example, support the following tasks:
- understanding complex dependencies
- analyzing permissions structures
- examining the impact of changes
- supporting data owners in their tasks
- creating recommended actions for individual directories
- highlighting problematic data or structures
The webinar also demonstrated how AI can be used for data owners: instead of merely providing them with a list of technical information, an automatically generated exposé can summarize the context of a directory and point out concrete next steps.
The AI remains a tool to support decision-making. The business decision about what happens to data and directories remains with the responsible company or the respective data owner.
Link repair: A small detail with a big impact
Particular attention is paid to repairing file links.
Before migration, files can be checked for existing links. This involves analyzing whether the links still work and which source files are connected to which targets.
After migration, the changed target paths can be used to restore the corresponding links.
This addresses a problem that could otherwise quickly lead to considerable manual effort and disrupted business processes.
Migration as an opportunity for the IT environment
A migration is often viewed as a necessary large-scale project that should be completed as quickly as possible.
The better approach may be to understand migration as a restructuring project.
Because a properly prepared migration can also help to
- reduce unnecessary data,
- lower storage and operating costs,
- remove outdated permissions,
- reduce security risks,
- make dependencies visible,
- secure business processes,
- sustainably improve the target structure, and
- involve business departments more strongly in the responsibility.
One central idea was therefore repeatedly emphasized in the webinar: What matters is not solely how much data was successfully migrated. It is equally important which data is deliberately not migrated.
Conclusion: A successful migration begins before the first copy process
File server and SharePoint migrations are not purely copy projects.
They are an opportunity to analyze existing structures, clean up data, rethink permissions, uncover dependencies, and deliberately design the target environment.
The path to a best-case migration therefore does not begin with the first migration job, but with the question: What do we actually have – and what of it do we really need?
Those who make data, permissions, dependencies, and responsibilities visible at an early stage and involve business departments in a structured way create the basis for a migration that not only works technically but also delivers long-term value for the company.
The platform migRaven.MAX presented in the webinar supports this approach with functions for analysis, Clean-up, auditing, data owner involvement, migration planning, readiness assessment, project control, monitoring, and link repair. In addition, AI can be used to evaluate information from the existing environment in context and support those responsible in making decisions and determining next steps.
Anyone planning a file server or SharePoint migration should therefore not only ask which migration tool can copy data. The more important question is: How does a technically necessary migration become a controlled, functionally sound, and sustainable transformation process?
What you take away from the webinar
- Why pure lift-&-shift migrations often lead to problems
- How RED data can be identified before migration and cleaned up together with the business departments
- Why legacy permissions should not be transferred 1:1 to the target system
- How file links and unknown dependencies become visible before they disrupt business processes
- How data owners are identified and involved in the migration in a structured way
- How readiness assessments, project control, and monitoring make a migration plannable
- How AI, based on the Knowledge Graph, supports decisions and next steps
How well do you know the data you want to migrate?
Which data is still needed? Which permissions are outdated? Which files reference paths that will change with the migration? And who in the business department decides on this?
In a personal presentation, we show how migRaven.MAX analyzes your file server and SharePoint environment and how this creates a plannable path to a best-case migration.
