Can we continue using WCF or should we modernize. Can you provide the details on why we need to modernize?

You can continue using Windows Communication Foundation (WCF) for your applications, but there are several reasons why modernization might be necessary:

1. Support and Maintenance: WCF is not actively being developed for new features, and Microsoft has shifted focus towards newer technologies such as gRPC. This means that while you can continue using WCF, you may miss out on improvements and support that newer frameworks provide.
2. Performance and Scalability: Modern alternatives like gRPC are built on top of HTTP/2, which offers better performance and scalability compared to WCF. gRPC is designed to handle a large number of clients and servers efficiently, which is crucial for modern applications.
3. Cross-Platform Compatibility: gRPC is platform-neutral and can be used with various programming languages, making it easier to integrate with other systems and services. WCF, on the other hand, is primarily tied to the .NET ecosystem.
4. Security Features: gRPC supports a variety of security mechanisms, including TLS and authentication, which are essential for modern applications that require secure communication.
5. Future-Proofing: As technology evolves, relying on older frameworks may limit your ability to adapt to new requirements and technologies. Migrating to modern frameworks can help ensure that your applications remain relevant and maintainable in the long run.

In summary, while you can continue developing with WCF, modernizing to frameworks like gRPC can provide significant advantages in terms of performance, scalability, security, and future compatibility.

References:

• What Is Windows Communication Foundation
• gRPC for Windows Communication Foundation (WCF) developers

Hello thanks for reaching out !

Define objectives: Identify why you’re modernizing (cloud, cross-platform, performance, security, maintainability).

• Inventory services: List endpoints, bindings, contracts, consumers, hosting model, and dependencies.
• Classify workloads: Separate internal vs. external services; note change velocity and criticality.
• Assess constraints: Confirm Windows-only vs. cross-platform needs, compliance, and scalability requirements.
• Decide the path: Choose to stay temporarily or modernize based on risk, ROI, and future roadmap.
• Select target stack: Pick ASP.NET Core (REST), gRPC, or CoreWCF per service’s needs.
• Map features: Translate WCF bindings and contracts to REST (OpenAPI) or gRPC (.proto); plan security with TLS + OAuth2/OIDC.
• Plan migration slices: Use the strangler pattern; prioritize high-value endpoints and define incremental phases.
• Set foundations: Establish CI/CD, observability (logs, traces, metrics), and standardized authentication/authorization.
• Implement services: Build new endpoints to match behavior and error semantics; decouple DTOs from domain models.
• Add adapters/gateways: Provide WCF-to-REST/gRPC translators and route traffic via an API gateway or reverse proxy.
• Test thoroughly: Validate functional parity, load/resilience, and security; compare against WCF baselines.
• Pilot rollout: Do canary releases to a small cohort; monitor and keep a rollback plan ready.
• Cut over in phases: Move consumers, update configs, version APIs, and deprecate legacy bindings with clear timelines. Decommission legacy: Drain traffic, archive logs, remove WCF endpoints/servers, and update documentation/CMDB.
• Optimize post-migration: Tune performance, manage costs, and enforce API/security standards and SLOs.

If staying on WCF short-term (parallel actions)

• Harden security: Enforce TLS 1.2+, modern ciphers, strict auth; review message/transport security.
• Stabilize operations: Centralized logging, health checks, trace correlation; patch Windows and .NET Framework.
• Plan an exit: Define triggers for migration and a target (REST/gRPC/CoreWCF) with a realistic timeline.

if you are on net48, your whole stack is on maintenance mode (no feature updates), so it mostly depends on your migration to .net core timeline.

WCF for core is now open source. You should follow the repo for support activity

https://github.com/CoreWCF/CoreWCF

For new core webapi projects you should probably pick REST Open api, which is not vendor specific. Or pick gRPC which is most like WCF.

WCF is still the only option for SOAP api.