Отдельно от миграционных проектов мне нравится браться за исследовательские задачи.

Сейчас, с развитием общих стандартов (a.k.a “Суем Кубер повсюду и переписываем все, что есть, на Golang”), таких проектов в компаниях становится все меньше и меньше. Причины тому просты - то, что вы только задумались сделать, сделали за вас во многих фирмах не один раз. И пусть не все исследования попадают в production, изучать что-то новое всегда полезно (даже если в результате исследования выясняется, что от какого-то продукта лучше держаться подальше).

По умолчанию исследовательские задачи ставятся перед архитекторами или инженерами из R&D групп. Под это дело выделяется определенный бюджет или выдается карт-бланш, резервируются необходимые ресурсы, и люди приступают к изысканиям.
Первое, что попадается на глаза во время исследования - предмет оказывается совсем не rocket science, и вместо полноценного изучения, Proof-of-Concept или Minimal Viable Product делаются по очеркам из интернета и всяких блогов исследователей-энтузиастов.
На выходе получается годная заготовка, которая неожиданно валится во время промышленной эксплуатации.

Во избежание такого, нужно планировать весь проект, словно речь идет не о разведке terra incognita, а о написании новой фичи для бизнеса.
Обычно я разбиваю исследование на следующие этапы:
1. Суть проблемы. Когда запрос на исследование приходит от stakeholder’ов, то входных данных очень мало для подробного анализа. Всегда стоит пообщаться с бизнесом пару лишних раз, чтобы понять какую именно проблему они хотят решить. Даже если к вам приходит СТО и просит рассмотреть переезд с MySQL на PostgreSQL, вне зависимости от компетенций человека надо от него добиться “Почему”.
2. Потенциальные решения. Их всегда должно быть несколько. Если вы решили “запаковаться” в Докер, то нужно выделить несколько систем контейнерной оркестрации под изучение.
3. Составление критериев исследования. Такое чаще всего надо делать, когда вы изучаете инструментарий под одну конкретную цель (например мониторинг). Сядьте с коллегами по цеху, набросайте критерии, поставьте “тяжесть” напротив каждого. Благодаря этому сможете составить стандартизированный сценарий исследования и максимально объективно оценить предмет изучения.
4. Новое должно быть лучше. Именно лучше, а не “не хуже”, иначе вы никогда не защитите свое исследование перед бизнесом. Преимущества нового должны лежать не только в технологической среде, но и экономической - “доход” (или ликвидация риска финансовых потерей за простой) не должна быть ниже стоимости обслуживания (под которую попадает и железо, и поддержка, и лицензии, и человеко-часы на управление).

Опять же, берясь за любое исследование, не стоит “влюбляться” в новый продукт. За несколько лет работы над исследовательскими задачами из моих проектов только 5-10% PoC увидели свет. Оставшиеся были завернуты по причине смены приоритетов, либо были слишком дорогими для внедрения и последующей эксплуатации.
И это на самом деле не плохо! Гораздо хуже, когда в вашей конторе используют хрупкий DCOS, потому что он ну очень понравился разработчикам.