The replacement approach

Services are replaced in big chunks, only taking into account their external interfaces or effects. This black-box approach completely replaces existing functionality coding with an alternative from scratch. Once the new code is ready, it gets activated and the functionality in the old system is deprecated. 

Note that this does not refer to a single deployment that replaces the whole system. This can be done partially, chunk by chunk. The basis of this approach is that it creates a new external service that aims to replace the old system.

The pros of this approach are that it greatly helps in structuring the new service, as it doesn't inherit the technical debt, and allows for a fresh look at an old problem, with hindsight.

The new service can also use new tools and doesn't need to continue with any old stack that is not aligned with the strategic views on the future direction of the technology in the company.

The problem with this approach is that it can be costly and can take a long time. For old services that are undocumented, replacing them could take a lot of effort. Also, this approach can only be applied to modules that are stable; if they are developed actively, trying to replace them with something else is moving the goalposts all the time.

This approach makes the most sense for old legacy systems that are small, or at least have a small part that performs limited functionality, and are developed in an old tech stack that's difficult or is no longer considered desirable to maintain.