La migration big bang consiste à basculer d'un seul coup d'un ancien système vers un nouveau, lors d'une date de mise en production unique. L'opposé direct du strangler fig pattern — une approche risquée mais parfois la seule techniquement possible.
Pourquoi c'est risqué
Aucune valeur n'est livrée avant le jour J. L'effet tunnel est maximal, les retours utilisateurs arrivent trop tard, et un problème en production impose un rollback total. Les dépassements de délai et de budget sont systématiques.
Quand c'est justifié
Dans de rares cas : ancien système impossible à interfacer (pas d'API, pas de base exposée), migration de données qui doit être atomique, ou refonte d'un outil interne à faible criticité. Dans tous les autres cas, préférer une migration progressive.
Le big bang n'est pas une stratégie, c'est un dernier recours. Quand on ne peut pas faire autrement, il faut sur-investir dans les tests, la réversibilité et la communication.