This is a solution in search of a problem. I reject the premise of the question. I would equip my team with objectives worthy of their talents, trust and autonomy, and the resources to utilize the best available tools for the job.

I'm really good at this topic :) here is the recipe: 1. Before blindly choose micro-services, we should focus on why legacy systems became legacy: what are the pain points right now? why it cannot resolve by refactoring itself? why it can resolve with micro-service? how micro-service could prevent the pain points in future? 2. Why micro-service? is there other system patterns to solve this legacy systems? do we have a good infra to support micro-services? e.g log tracing cross services; do we have a good engineering exercise that owns both product development and operation? 3. If the decision is made, I'd go with cloud providers as they actually have a good basic template to support. Don't build it in-house.

Microservices or not, change management is all about people, communication and a realistic plan. So, build the change team with the right key people who can sponsor, take decisions, and influence. Make sure to communicate continuously and have an open door policy for anyone who has ideas, concerns, or just want to talk. And have a plan, a realistic one which is also gradual and aligned with the business.

To navigate the complexities of legacy systems, equipping a team with a MicroServices approach can bring transformative benefits, promoting independent scalability by service, ensuring the system can efficiently handle increased demand, reusability is enhanced as each service is modular and can be leveraged across different parts of the application or even in new projects and availability improves since each service is isolated, meaning failures in one component won’t necessarily impact others. This approach encourage low coupling creating clear boundaries between services, enabling easier updates, better fault tolerance, and faster deployment cycles. It empowers teams to modernize, providing a foundation for agile, future-ready systems.

Para preparar sua equipe para a transição para microsserviços ao eliminar sistemas legados, ofereça treinamento abrangente, incentive a colaboração multifuncional e implemente mudanças incrementais.

One thing I think about is focus on making the cross cutting concerns like monitoring and security seamless. The other thing is focus on quick wins. Quick wins will gain the organization’s trust, gain experience across the organization. The third and final point is use LLM and generated code, from day 0. The results will be x2, x3 faster and cheaper.

To ensure an effective transition to microservices, focusing on Bounded Contexts is essential. Dividing the system into well-defined contexts, where each service addresses a specific business area, modularizes responsibilities and enhances team autonomy. Clear boundaries strengthen cross-functional collaboration, enabling teams to operate independently and build expertise within their context. Incremental changes and gradual adaptation support a smoother transition without overwhelming workflows. - Identify Contexts - Separate functional areas - Define Boundaries - Set clear boundaries - Assign Teams - Give autonomy to each context - Implement Gradually - Apply incremental changes - Encourage Collaboration - Promote team communication

In my experience microservices are many times confusing. Multiple interpretations of what a microservice is, lead to a complex and messy place. Microservices really works when trying to mimic your organization structure. When Decoupled teams needs to work in really diferent things, or when you have enouth standardization that teams can navigate through many services with ease

This sounds like the switch to client-server from mainframes. My approach was not to rewrite legacy systems but to build new functionality using the client-server model. Eventually the legacy system grows obsolete and can be end of lifed.