WCF to modern .NET, in the right order

The WCF estate can be moved. There is a wrong order to do it in, and most teams pick it. The sequence that works, current as of .NET 10.

Pixel drawing of an old plug and cable pointing toward a new panel

We have met your WCF app before. Framework 4.8, a service layer that grew for a decade, config files with bindings nobody has dared touch since the person who understood wsHttpBinding left. It can be moved. There is a wrong order to do it in.

The wrong order: rewrite the services as REST "while we're at it," retarget the runtime, and modernize the hosting, all in one program. That is three migrations stapled together, and when it slips, nobody can say which of the three is slipping.

The right order, one variable at a time:

  1. Get the code buildable on modern tooling first. SDK-style projects, package references, the compatibility analyzers. No behavior change. Microsoft's upgrade tooling does the mechanical share; budget human weeks for what it flags and skips.
  2. Decide the service contract's future out loud, per service, three bins. Bin A: internal service, callers you control. Move the contract to plain HTTP or gRPC; the WCF ceremony was never buying you anything here. Bin B: external partners coupled to SOAP semantics. CoreWCF, the community port, keeps the wire format alive on modern .NET; know that it is a subset, not a resurrection, and audit your bindings against it before promising dates. Bin C: services whose consumers are gone. You would be amazed. Scream test, then delete.
  3. Retarget to the current LTS. .NET 10 shipped November 2025 with support into 2028, which is the runway a legacy estate actually needs. Do not land a multi-year migration on a short-support release to feel current.
  4. Only now change hosting, containers, or architecture, if the inventory says it pays.

Two traps with dates on them. First, .NET Framework 4.8 is not dying tomorrow; it ships with Windows and will be patched for years. The pressure is real but it is indirect: libraries, hiring, tooling, and the OS refresh cycle underneath (Server 2016 support ends January 2027). Use the real deadline, not a vendor mood, to sequence. Second, behavior parity is a test suite, not a feeling. Golden-request suites against old and new, run in parallel, diffed nightly. SOAP faults have personalities. Learn them before the customers do.

Budget it straight: the runtime retarget is the cheap third. The contract decisions are the expensive third, because they are organizational: every Bin B service means a partner conversation someone has been avoiding since 2019. Book those calls in week one. The code will wait; the partner's release calendar will not.