WCF to CoreWCF migration: when it pays off, how it is done and what it costs

The IT manager of a logistics company near Verona calls me about something else: he wants to update the server running the warehouse system. I ask where the code that talks to the handhelds, the customer portal and the courier software lives. He answers, in a tone I know well, that there is "a service" built in 2011 by a consultant who is long gone. It is called OrdiniService.svc, it runs on Windows Server 2012 and fourteen programs depend on it. Nobody has opened the project in three years. Everybody uses it every minute.

WCF to CoreWCF migration is the cheapest path when the connected clients cannot be touched: keep the same SOAP contract, move the server to .NET 10 and leave every calling program unchanged, for roughly 12,000-30,000 euro and four to eight weeks on a medium service. This guide explains how to tell whether you need it, which paths exist, what each costs and where the work usually breaks. For the bigger picture of the whole application, start from migrating from .NET Framework to .NET 10.

Why is WCF the most dangerous piece of your legacy software?

WCF on .NET Framework still works, but Microsoft does not port its server side to modern .NET, so every year without a plan raises the cost of leaving. The risk is not that it stops tomorrow. It is that nobody remembers how to touch it when you must. The client libraries exist on modern .NET, so a new program can call an old service; the server does not exist in .NET 10. Microsoft pointed to gRPC and REST as alternatives, and the community built CoreWCF, which brings the WCF model to ASP.NET Core.

A service with one internal client, in a closed network, can wait. It becomes urgent when someone outside the company calls it, because then you no longer decide when to change.

Which paths exist: CoreWCF, gRPC, REST or a rewrite?

There are four paths: stay where you are, move to CoreWCF keeping the SOAP contract, replace it with gRPC or REST, or rewrite everything. The choice depends on one thing: can you modify the programs that call the service?

Costs are orders of magnitude at 600 euro per day for services with twenty to forty operations. For the trade-off between rewriting and improving, see rewrite or refactor your software.

How do you inventory a WCF service before touching the code?

The inventory answers four questions: which operations are exposed, who calls them, how callers authenticate and which parts of web.config really matter. It takes three to five days and is worth half the estimate. Read the configuration file line by line, count requests per operation from seven days of IIS logs (live, dormant, dead), list every client with owner and source code status, and record the security mode of each. In the Verona case, 38 operations split into 21 live, 9 dormant and 8 never called; fourteen clients turned out to be nine programs, one of them an old Delphi executable nobody could recompile. That settled the choice: the contract could not change by a comma.

Also collect recorded calls, request and response, at least three per live operation. They become your tests.

What changes with CoreWCF and what stays the same?

CoreWCF reproduces the WCF model on ASP.NET Core: contracts, attributes and bindings are the same, while hosting moves from the .svc file and web.config to code in Program.cs. Two details matter more than the rest. The first is the Namespace on contract and data: it ends up in the SOAP messages, and one wrong letter makes existing clients reject the answers. The second is the Order of data members: field order is part of the contract. CoreWCF covers the common bindings (BasicHttp, partial WSHttp, NetTcp) but not everything: distributed transactions (WS-AtomicTransaction) and reliable messaging are missing or limited, and those points must be redesigned with an idempotent operation and a queue. Data access often needs migrating from Entity Framework 6 to EF Core, and dependencies become native, as in dependency injection in C#.

How is the migration done step by step?

The method that lowers risk is running old and new servers side by side for a few weeks, sending the same traffic through both and moving clients one at a time without switching anything off until results match. It is the strangler fig pattern applied to services. Six steps: freeze the old service; extract the business logic into a library; write tests on the recorded calls, comparing old and new responses; build the CoreWCF service next to the old one; move traffic client by client through a proxy; switch off the old server only after a full month-end close. Every step can be undone in minutes, so nothing happens at night.

How much does it cost and how long does it take?

A medium WCF service (twenty to forty operations, three to ten clients, one database) costs 12,000 to 30,000 euro to move to CoreWCF with the contract unchanged, in four to eight weeks, and two to three times as much if you rewrite the contract in REST or gRPC and adapt the clients. Three items move the total: the quality of the existing code, the security model (integrated Windows authentication costs far more than an API key) and the number of clients you cannot leave intact. Keeping the old Windows server alive costs 1,500-3,000 euro a year, so over five years the machine alone is close to the migration cost. For whole-software prices see how much custom business software costs.

Which mistakes break a WCF migration?

Five mistakes break most migrations: changing the message namespace, losing null and date behaviour, ignoring the old transport security, underestimating message size limits and forgetting operations that use transactions. The most serious is security that silently disappears: a service using Windows authentication on IIS, moved to Kestrel in a Linux container, answers everyone. The first acceptance question is what happens when you call without credentials; the right answer is a refusal, and it must be tested, not assumed. The sixth mistake is not technical: having no way back.

When should you leave SOAP, and where does AI help?

CoreWCF is a bridge, not a destination: it moves the server to modern .NET cheaply and lets you move to REST or gRPC one client at a time, when it makes sense. Choose REST for anything facing the web, partners or mobile apps (see minimal APIs or controllers in ASP.NET Core) and gRPC for internal services. Plan for the target runtime too: .NET 8 and .NET 9 reach end of support, so aim straight at .NET 10.

AI helps to read forgotten code, generate tests from recorded calls and translate XML configuration into code, as described in refactoring legacy code with AI. It must not decide the security model or touch the public contract.

The Verona manager ran this exercise with me. Fourteen clients in the logs, nine real programs, eight operations nobody called. The new CoreWCF service ran side by side in five weeks, the handhelds moved first, and the Delphi executable never knew anything had changed behind it. The old server was switched off after the month-end close.

If you have a WCF service in production and do not know where to start, come and talk: in the legacy software modernization path we start from the inventory, estimate cost and time for the path that fits your clients and decide what to touch first.