In the field of Electronic Mail Management, data migration is an essential step when moving to a new solution. It’s not simply a matter of transferring files — it’s often a genuinely complex process.
GEC having been firmly established in people’s minds for many years now, we’re operating in a replacement market, and Maarch is regularly faced with this challenge of migrating from legacy applications. This article presents our approach and methodology for an operation that has now become a standard part of any project.
An unavoidable migration context
In a digital ecosystem that is constantly evolving, GEC solutions used by public and private organizations are under growing pressure to adapt to new technical and functional standards.
Legacy tools, often frozen in place for several years, become difficult to maintain and struggle to meet new business requirements.
Migrating to more modern solutions, capable of meeting today’s requirements in terms of performance, data integrity, and regulatory compliance, therefore becomes unavoidable.
In this context, data migration is a delicate exercise…
It’s not simply about moving files from point A to point B, but about preserving the integrity of all metadata, reference data, and internal relationships. A rigorous strategy is essential to avoid any loss of information or degradation of data quality.
Choosing the right recovery strategy
Before committing to a data migration, it’s essential to carefully examine the available alternatives. This type of operation is often complex and can involve high costs and a significant workload, depending on the volume of data to be processed and the specifics of the source applications used.
The possible options are:
Option 1: Do nothing
“There is no problem that an absence of a solution won’t eventually solve…”.
To paraphrase Henri Queuille, you should always ask yourself whether doing nothing might be the answer.
Option 2:
The « From Scratch » strategy, which involves starting over from nothing, is a radical but relevant solution in certain contexts.
For example, when a government changes, the « republican doctrine » calls for the complete archiving of correspondence from the outgoing teams.
As a result, if the application being retired allows the document collection to be exported, this provides an additional guarantee in terms of data security and retention.
Option 3:
The strategy of keeping the existing application in read-only mode can be a viable option, provided you accept the possibility of data loss after a few years.
This approach means dealing with hardware and system obsolescence, as well as the risk of failures that could render the application unusable on new infrastructure.
The application is therefore kept in its original configuration, accessible to staff until it becomes completely obsolete. While cost-effective and suited to the short or medium term, this solution remains impractical for users on a day-to-day basis.
Option 4:
The strategy of migrating to an archive database is based on the principle that transfer solutions are similar. This strategy involves carrying out a simplified migration in an environment separate from production, which avoids complex mapping between entities, mail types, and groups across the two systems.
Mail items are therefore migrated and assigned to a generic user, of the « Archivist » type, who is the point of contact for retrieving documents. This approach eliminates any risk of contaminating the production database, and the migration can be carried out at any point in the project.
Highly valued by our teams, this method offers great flexibility in how the project unfolds, since data migration can be carried out in parallel, without blocking subsequent steps.
Another major advantage is that the technical environment is constantly kept up to date and identical to production, allowing the archive database to benefit from technical developments over the long term. This is, for example, the strategy chosen by the Ministry of Foreign Affairs for its data migration.
A proven methodology for a successful migration
At Maarch, we have developed a clear, secure strategy to ensure the success of data migration:
1. Precise planning
We start by defining a detailed migration strategy in a Data Migration Document (DRD). This document lists the mapping between the source and target databases, the control procedures, and the migration timeline.
Transferring data between environments is also one of the key points of this phase. That’s why, once Maarch Courrier has been configured according to business needs, we provide the client with a mapping table between the Maarch reference data and the source reference data, leaving it up to the client to specify the exact correspondences.
2. Rigorous preparation
Before starting the transfer, we carry out a precise count of the data (contacts, users, entities…) used to establish a control reference. This count makes it possible to detect inconsistencies and to plan for rejection files in case of errors when importing into the target database.
A particularly effective strategy is to carry out the migration into a dedicated archive database, separate from the production environment. This choice helps secure the process by avoiding any disruption to the live system. Data is assigned to an « Archivist »-type profile responsible for centralizing access and search requests. This method offers additional flexibility, since the migration isn’t a blocking milestone, allowing it to be carried out in parallel with the rest of the project.
When data migration takes place between two solutions with an identical, up-to-date technical environment, this allows for a faster go-live. This is, for example, the approach adopted by the Ministry of Foreign Affairs for migrating from Neoledge Elise.
3. Secure transfer
At Maarch, data injections are systematically carried out via the target platform’s REST APIs, ensuring compliance with the database’s integrity rules.
During execution, rejected records are corrected and reprocessed as part of an indexing-based recovery, being handled and logged continuously to allow for the rapid correction of anomalies.
- Documents migrated identically are uploaded and indexed via WebServices.
- A global log tracks the number of successes and failures, as well as the migration’s execution time.
- Migration throughput observed on our SaaS environment exceeds 13,000 items of mail per hour (average calculated over an operation involving 250,000 items of mail, with or without attachments).
4. Quality control and validation
To ensure a successful data migration, it’s essential to implement rigorous validation, combining both technical and functional checks.
This dual validation ensures both data integrity and compliance with business expectations.
The technical check involves comparing the exact number of documents and the volumes of data exchanged between the source and target systems. This analysis is carried out both by the migration script and by the Maarch Courrier database, enabling precise control over data integrity.
The functional check, meanwhile, relies on a random sample of chrono numbers (10, 20, or 50) to allow for a direct comparison between the two applications. This step, more focused on the end user, provides an additional guarantee that the migration was successful, offering a symbolic validation that reinforces business teams’ confidence in the accuracy of the migrated data.
Thanks to this method, we have achieved a migration capacity of more than 13,000 items of mail per hour on our SaaS environment. Our expertise allows us to adapt to all types of environments, including solutions that are not very flexible.
Mind the confidentiality of the process
Migrating data always carries risks, whether the transfer is physical or digital.
Physical data transfer:
Using media such as hard drives or USB sticks would expose the data to the risk of loss or theft. To avoid this, we strongly recommend favoring encrypted media and secure transport
Digital transfer:
VPN connections or secure transfer platforms are convenient, but they must be properly configured, as network vulnerabilities could be exploited by malicious actors.
Data integrity:
Structural differences between the source and target databases can lead to errors or lost mappings. Careful preparation using data schemas and conversion rules is therefore essential.
Conclusion
Migrating a GEC solution is both a technical and a strategic challenge. With detailed planning, controlled execution, and rigorous validation, the move to a new platform can be made with complete confidence.
At Maarch, we have the experience and the tools to ensure a smooth transition, while guaranteeing the security and integrity of your data.
Dive deeper into the Maarch ecosystem
Choose the open-source reference
More than 100,000 users already trust us!
