.svg)
Un projet de migration informatique se joue avant la bascule, pas pendant. La plupart des migrations qui dérapent ne ratent pas sur la technique : elles ratent parce que personne n'avait cartographié l'existant, prévu un plan de retour arrière, ou testé la bascule à blanc. Le plan est ce qui sépare une migration invisible pour les utilisateurs d'un week-end de crise.
Voici la méthode en 7 étapes que nous appliquons sur le terrain, qu'il s'agisse de déplacer une messagerie, une base de données ou de mener une migration de parc informatique. Vous pouvez la reprendre telle quelle pour structurer votre propre projet.
What is an IT migration plan?
An IT migration plan is a document that describes how to transfer data, applications, or infrastructure from one environment to another without data loss or business disruption. It defines the scope, timeline, responsibilities, switchover method, and contingency plan in case of problems.
Migration is involved in a number of scenarios: moving from an on-premises server to the cloud, replacing outdated software, upgrading a fleet of workstations, or switching email providers. The type of migration determines the tools used, but the overall plan remains the same.
The real issue isn't the migration itself. It's data protection and service continuity. A poorly planned migration can end up costing far more than the project itself: data loss, billing disruptions, GDPR non-compliance, and a loss of trust among teams.
The 7 Steps of an IT Migration Plan
Step 1: Audit and Mapping of the Current Situation
Before making any decisions, you need to know exactly what you’re moving. This phase involves taking inventory of servers, applications, databases, data volumes, dependencies between systems, and network traffic. It’s also the time to identify redundancies, obsolete data, and inconsistencies—issues that are best resolved before the switchover rather than carried over to the new environment.
A sloppy audit is the leading cause of unforeseen issues during a project. A forgotten dependency between two applications, an underestimated volume, an expiring certificate: it’s these unaccounted-for details that throw a schedule off track.
Step 2: Defining Objectives and Scope
A migration is not an end in itself. It addresses a need: to reduce technical debt, improve security, lower maintenance costs, and enable remote work. Clarifying the objective makes it easier to make trade-offs later on, because any real-world project requires compromises between timeline, budget, and scope.
This is also the stage at which we establish the success criteria. Specifically: what needs to be working on Monday morning after the switchover for us to consider the migration a success? Without these criteria clearly defined in writing, it is impossible to objectively validate the project.
Step 3: Choosing a switchover strategy
There are two main approaches, and the choice between them shapes the rest of the project.
A Big Bang migration transfers everything at once, usually over a short period (a weekend). It’s faster and less expensive, but riskier: if something breaks, everything breaks at the same time.
A phased migration is carried out in batches (by department, by site, or by user group), with a period of coexistence between the old and new environments. It takes longer and is more complex to manage, but it minimizes risk and allows for course corrections between batches.
The right choice depends on the volume of data, tolerance for downtime, and the criticality of the data. An SME with 30 email accounts can switch over in a single sweep on a Friday evening. An organization with several thousand workstations will migrate gradually, over several weeks.
Step 4: Preparing the New Environment and Mapping
This step prepares the target system and defines the conversion rules. We configure the new environment (licenses, access rights, security, DNS), and define the mapping: which source data corresponds to which target data, and according to which transformation rules.
This is a technical but critical phase. For an email migration, this is where we prepare directory synchronization, DNS records (MX, SPF, DKIM, DMARC), and access permissions. For a data migration, this is where we define the mapping rules between the source and target schemas.
Step 5: Testing and Pilot Migration (Dry Run)
No major migration happens without a dry run. A dry run involves migrating a representative sample—without any actual data—to verify that the process works and measure the actual transfer time.
This test run uncovers issues while they’re still minor: a format that doesn’t work well, a larger volume than expected, or a missing permission. It’s better to discover these issues in a test batch than across the entire system during a full migration.
This is also the stage at which we break the migration down into manageable batches. In our messaging projects, for example, we schedule batches by department, by site, or by criticality level, rather than migrating everything all at once. This allows us to maintain control and validate each batch before moving on to the next.
Step 6: Go-Live and Fallback Plan
The official switchover. This is the culmination of the process, and it is also the moment when the fallback plan comes into its own. Before the launch, a complete and verified backup of the source environment must be in place, along with a clear procedure for rolling back if a critical criterion is not met.
To minimize the impact on business operations, the migration should ideally be scheduled during non-business hours (evenings, weekends). Enhanced support must be available during and immediately after the migration, as user issues tend to surface in the first few hours.
Step 7: Validation, Monitoring, and Support
The migration doesn't end with the go-live. You must verify that the success criteria defined in Step 2 have been met, check the integrity of the migrated data, and stabilize the environment.
This is also the aspect that is most often overlooked: user support. A technically flawless migration that is poorly explained leads to resistance, support tickets, and a perception of failure. Communication, training, and post-migration support are part of the plan—not just a bonus.
Big Bang or gradual migration: which should you choose?
| Criterion | Big Bang | Progressive |
|---|---|---|
| Duration | Short (a weekend) | Long (weeks/months) |
| Cost | Lower | Higher |
| Risk | High (everything changes in an instant) | Controlled (in batches) |
| Coexistence | None | The old and the new coexist |
| Suitable for | Small volumes, low criticality | Large volumes, high criticality |
| Backspace | It's hard once you get started | Possible between lots |
In practice, many projects take a hybrid approach: a phased pilot on a test service, followed by a broader rollout once the method has been validated.
The most common pitfalls encountered in the field
Some pitfalls aren't mentioned in the guides because they only become apparent during production. Here are the ones that come up most often in our projects.
Third-party applications that depend on the migrated system. This is the classic pitfall—and the one most often overlooked. A copier that scans to an email inbox, fax software, a business application that authenticates on the old server: these dependencies aren’t visible anywhere in a standard inventory, and they break the day after the switchover if no one has identified them beforehand. This is exactly what the audit phase is designed to uncover.
Local archives. During an email migration, PST files stored on user devices or in third-party archives are often overlooked. Users rely on them, and no one realizes they’re missing until they’re requested.
Managing rights and delegations. Shared folders, delegations, and permissions accumulated over the years: if you don’t map them out beforehand, you’ll have a hard time reconstructing them later.
Underestimating the audit phase. The three points above all stem from the same root cause. We want to move quickly, so we skip the detailed mapping, and then we end up having to deal with forgotten dependencies right in the middle of the migration.
Forget about the fallback plan. Migrating without a verified backup or rollback procedure is like playing without a safety net. If the switchover fails, you need to be able to cleanly revert to the original state.
Neglecting users. A migration is as much a people-oriented project as it is a technical one. Without communication and training, adoption will fail even if the technology is flawless.
Sample IT Migration Plan (for copying)
Here is a template outlining the 7 steps in the form of an action plan. Copy it into your project management tool and adapt the deliverables to your specific context: it works just as well for an email system as it does for a fleet or a database.
| Phase | Key Actions | Deliverables | Exit criteria |
|---|---|---|---|
| 1. Audit | Inventory of servers, applications, and data; mapping of dependencies and data flows; identification of obsolete data | Mapping of the current environment, list of dependencies (including third-party applications: copiers, fax machines, line-of-business applications) | The inventory is comprehensive and has been validated by the business teams |
| 2. Objectives | Defining the scope, budget, and timeline; drafting the success criteria | Guidance Note, Written Success Criteria | Each criterion is measurable (“billing is up and running by 8 a.m. on Monday”) |
| 3. Strategy | Big Bang / progressive / hybrid options; division into batches if necessary | Documented migration strategy, batch schedule | The strategy has been approved by management and IT |
| 4. Preparation | Configuration of the target environment (licenses, permissions, DNS, security); source-to-target mapping rules | Operational Target Environment, Mapping Document | The target environment passes the technical acceptance tests |
| 5. Tests | Dry run on a representative sample; measurement of actual transfer times | Pilot Migration Report, Revised Schedule | The pilot batch was migrated without any critical issues |
| 6. Toggle | Verified full backup; failover during non-business hours; enhanced support | Rollover procedure, rollback procedure | The success criteria for Phase 2 have been met |
| 7. Validation | Data integrity checks; communication and training; stabilization | Revenue Report, Migration Summary | Users are working as usual, and support is back to normal |
Should you outsource your IT migration?
A migration requires specialized expertise for a limited period of time. For an in-house IT team, this often means taking on a project in addition to day-to-day operations, involving high risk and specialized tools that must be mastered. That is why many organizations entrust their critical migrations to a specialized service provider, which brings a proven methodology and experience with similar projects.
Chez IT Systèmes, nous accompagnons des projets de migration depuis 2010, de la messagerie au parc complet : plus de 2 millions de boîtes aux lettres migrées vers Exchange Online depuis 2010 par nos équipes. C'est ce qui nous permet d'anticiper les pièges décrits plus haut avant qu'ils ne deviennent des incidents.
To learn more about our approach and areas of expertise, explore our expertise in IT migration.
A successful IT migration plan consists of seven steps: assessing the current environment, defining objectives, choosing a migration strategy, preparing the target environment, conducting a dry run, executing the migration with a contingency plan, and then validating and providing support. While the technical aspects are important, it is the preparation and support that make the difference between a seamless transition and a crisis-filled weekend.
FAQ
What are the steps involved in an IT migration?
An IT migration consists of seven steps: auditing and mapping the existing environment, defining objectives and scope, selecting a migration strategy (Big Bang or phased), preparing the target environment and mapping it, testing and conducting a pilot migration, the official migration with a fallback plan, and finally, validation and user support.
How long does an IT migration take?
The duration depends on the scope of the project. A simple email migration can be completed over a weekend, while a full infrastructure migration or one involving several thousand workstations can take several weeks, or even several months in the case of a phased rollout.
What is the difference between a Big Bang migration and a phased migration?
A "Big Bang" migration transfers everything at once, which is faster and less expensive but carries greater risk. A phased migration proceeds in batches with a period of coexistence between the old and new environments: it takes longer and is more complex, but the risk is managed, and it is possible to revert to the previous state between batches.
How can you prevent data loss during a migration?
Data loss protection relies on three key components: a complete and verified backup of the source environment prior to the switchover, a dry run migration to validate the process, and a fallback plan to revert to the initial state if a critical issue arises.
Should you hire a service provider for an IT migration?
Outsourcing allows you to leverage a proven methodology, specialized tools, and experience from similar projects, thereby reducing the risk of incidents. It is particularly recommended for critical or large-scale migrations, where an internal team would have to manage the project in addition to day-to-day operations
.svg)