2014 – 2017 · Saint-Étienne, France · On-site
Production engineer (mergers and data migration)
Eovi-mcd — A major French mutual insurance group
Two successive combinations over three years. In 2014-2015, the mutual insurer absorbed an entity whose membership approached its own and whose information system was an in-house solution, along with Myriade, already on the same software package. The second case was settled with migration scripts; the first took several months. In 2016-2017, preparation of the Aesio group brought together Adrea and Apreva, both on the same package.
On the operations side, the 2015 data migration was prepared with the migration project manager, the absorbed entity's developers and the software vendor: acceptance environments provisioned for test campaigns, successive loads, verifications — all on top of daily operations. Procedures specific to the absorbed entity were folded into the operations scripts, as pre- and post-processing. The migration scripts for the customer relationship module were written and tested in this context.
The absorbed entity's three operations staff joined the team, taking it from three to six, and dual operations were held until the cutover. The production migration spanned several days, each member of the team relaying in eight-hour shifts to launch and monitor the jobs. During the operation, a scope that had not been assigned was taken over so as not to hold up the migration.
Achievements
- 8
Preparation in acceptance environments
Environments provisioned for test campaigns, successive loads and verifications, carried out on top of daily operations. Procedures specific to the absorbed entity folded into the operations scripts as pre- and post-processing.
- 4
Transactional switchovers handed to the scheduler
The startup and shutdown scripts, old and unreliable in ways nobody could characterise, were rewritten and commented. With their reliability restored, switchovers nobody had dared delegate could be automated.
- 6
Chaining errors eliminated
Manual placement, done from a printed schedule plan, exposed the night to a job linked to the wrong predecessor or successor. The automated run produces the same result every time.
Generic parameterised batch launcher
Job name, trigger event and degree of parallelism passed as parameters; pre- and post-processing resolved by convention rather than hard-coded.
Coverage of the whole batch plan
Each job had until then been declined into as many launchers as it had functional scopes, created by copy and parameter change.
Taking over an unassigned scope during the cutover
Stepping in during the production migration on a part that fell to another contributor, so as not to hold up the data migration.