Миграции
Речь здесь не о миграции в смысле баз данных, а о миграции в смысле с одной системы на другую. Чтобы вероятность успеха была ненулевая, лучше всего делать подобные миграции в стиле спецоперации - резко и не затягивая. Почему?
Все упирается в процессы и людей. Можно прикинуть, сколько времени обычно проходит до очередной смены курса в компании, сколько времени в среднем работают. Если миграцию не провести быстро, она сразу же исчезает с глаз менеджмента и становится фоновой головной болью программиста. Приоритет низкий, поэтому можно сразу смело ожидать, что миграция будет тянуться и тянуться. Казалось бы, ну и ладно, но есть еще один фактор - время жизни самой системы. У вас была система А, которая устарела. Вы решили перейти на систему Б, которая вроде получше, но переход так затянулся, что и Б стала старовата, а надо уже переезжать на В. В результате в ходу сразу три разныих системы, которые делают одно и тоже, но неможно по-разному и, конечно несовместимо. И все, привет.
Статус
Мелкий вопрос с большими последствиями. Любой процесс моделируется в виде отдельных состояний и переходов между ними. В системах побольше будут очереди разных типов, но у них должна быть скорее вспомогательная роль передачи данных, а не основная логика. Менее понятно - что именно называть статусом, а что нет. Часто можно отличить так - если новый кандидат в статусы - это просто слегка модифицированный старый, то скорее всего речь идет не о статусе, а о свойстве, которое процесс может иметь в данном состоянии. Сильно много свойств, как и состояний ни к чему хорошему не приводят - количество веток в коде растет, думать о таком коде очень сложно.
