Specifically, there are two parts to this:
mw-web and mw-api-ext services: next releases
The two large external-facing services, mw-web and mw-api-ext, will need directly addressable (i.e., dedicated LVS services, discovery addresses, etc.) deployments in the same manner as the "next" release we've created for mw-debug in T372604.
This is to support cookie-driven migration of external traffic to 8.1. Ideally, we should batch these together in order to minimize the number of complex / disruptive operations (e.g., LVS service turnups).
All large services: migration releases
All "large" services will need an additional "migration" deployment that is routed via the existing "main" release, similar to how the "canary" releases work.
This is to support a capacity-based fractional migration of internal and cookie-less external traffic (i.e., progressively shifting replica counts from the "main" release to the "migration" release, which route via the same Endpoints object). These "migration" releases will (and indeed must) be initially scaled to zero replicas.
Services in scope: mw-api-int, mw-api-ext, mw-jobrunner, mw-parsoid, mw-web
Other lower-traffic services (e.g., mw-misc, mw-wikifunctions) or non-traffic-serving MediaWiki use cases (e.g., mw-script) are not in scope, and will be migrated as one-offs.