Legacy و Integrations

I separate the message protocol from its description. SOAP defines an XML envelope with a body, optional headers and faults. WSDL describes the service operations, message contracts, bindings and endpoints, while XSD defines the XML types those messages use. I usually generate a typed client from the WSDL rather than build envelopes manually. Before integrating, I check the SOAP version, binding and security requirements because a generated proxy alone does not guarantee interoperability.

I treat an XML element's identity as its namespace URI plus local name. Two elements called Invoice can represent different contracts if their namespace URIs differ. Conversely, changing a prefix from a to b does not change meaning when both map to the same URI. When debugging SOAP, I compare qualified names and schemas rather than just the visible tag spelling. I use XML APIs or generated serializers so namespace handling and escaping are explicit.

I generate a proxy from a trusted WSDL using dotnet-svcutil or Visual Studio's WCF Web Service Reference. The generated code uses System.ServiceModel client packages. I inspect the generated operations and configure the appropriate binding, endpoint, authentication, timeouts and message limits. I keep those types behind an adapter implementing our own interface. I also test faults and timeout behavior, and close healthy channels or abort failed ones instead of reusing a faulted client.

I distinguish WCF client packages from the original WCF server runtime. Modern .NET can consume supported SOAP contracts with System.ServiceModel clients, but it does not host the original Framework WCF server. I evaluate CoreWCF when existing SOAP clients must remain compatible, checking bindings, security and behaviors individually. If we control all consumers, I may design a gRPC contract instead. That changes the wire protocol and clients, so it is a separate migration decision.

I use an anti-corruption layer to keep a legacy or partner model from spreading into our domain. It contains adapters and translation rules for data, behavior and failures. For example, an external invoice status code becomes our own meaningful status, and unknown codes are handled explicitly. This gives consumers a stable interface and keeps partner-specific changes localized. I test the mapping against real contract examples, while avoiding unnecessary abstraction when the integration is already simple.

I migrate one capability at a time while old and new implementations coexist behind a routing boundary. A proxy sends migrated routes to the new application and leaves the rest on the legacy system. Each slice has tests, observability and a rollback plan. I also define data ownership and cross-cutting concerns such as authentication before moving traffic. The pattern reduces the size of each change, but coexistence costs money and complexity, so I track explicit legacy retirement criteria.

I start with dependency and platform assessment, production baselines and characterization tests. Then I choose a small business slice and upgrade its leaf libraries, using netstandard2.0 or multi-targeting only where sharing with Framework is needed. I replace System.Web boundaries, evaluate WCF hosting, and validate EF query behavior and configuration changes separately. I use migration tooling for mechanical edits, review its output, and move traffic gradually with rollback. A successful build is only the beginning of validation.

I write characterization tests to capture what existing code currently does before changing its structure. They are useful when requirements are incomplete or behavior has evolved over years. I select representative inputs, record outputs and side effects, and make unstable values deterministic where possible. The tests may preserve a known defect temporarily, so I label that explicitly and change it in a separate agreed fix. Their purpose is to expose accidental behavior changes during modernization.

I think of a seam as a place where I can change a dependency's behavior without rewriting the business logic being tested. Constructor injection for a clock, a file reader or a payment client is a common example. I introduce the smallest useful seam, preserve behavior with characterization tests, and supply a deterministic test implementation. I avoid a broad redesign just to add one test, because that increases the unverified change before the safety net exists.

I treat EF Core as a different ORM implementation rather than an EF6 package upgrade. Query translation, relationship conventions, loading, tracking and migrations can differ, so code that compiles may behave differently or issue more queries. I compare representative results, generated SQL and performance against a real database. I also plan schema evolution independently so both application versions remain compatible. Depending on dependencies, I may postpone the ORM migration to avoid combining too many risks.

I save the business change and an outbox record in the same local database transaction. A dispatcher reads pending records, sends them with a stable message identifier and marks them complete after acknowledgment. If it crashes after sending, the record can be sent again, so the receiver must deduplicate and apply its effect atomically where possible. I monitor backlog age and failed attempts, and keep a repair path for messages that cannot progress automatically.

I do not interpret a timeout as proof that the payment failed. The provider may have completed the charge before the response was lost. I reuse the original idempotency key if the provider supports it and understands its retention rules, or query the payment by a stable business reference. Without either capability, I record an unknown outcome and reconcile before resending. A generic retry policy can otherwise turn a temporary network problem into a duplicate charge.

I use an outbox to protect local event recording, but it cannot prove that both systems represent the same final business state. Mapping defects, manual edits, rejected records and partner-side failures can still create differences. Reconciliation compares stable business keys, versions, statuses and monetary totals after allowing for expected delay. It classifies discrepancies and either repairs them idempotently or raises an actionable exception. I audit repairs so reconciliation does not become an invisible source of new changes.

I check the actual protocol rather than treating secure file transfer as one interchangeable option. SFTP is a file-transfer protocol over SSH, while FTPS is FTP secured with TLS. They use different clients and server configurations. For SFTP I verify the server's host key and use managed credentials or keys. Encryption protects the connection, but I still need file completeness checks, duplicate detection and acknowledgments to know whether the business import succeeded.

I agree the schema, encoding, quoting rules and file completion protocol first. I stream records through a proper CSV parser into staging, validate them, and apply bounded batches with stable business keys. I track file identity and durable progress so replay after a crash is safe. Invalid records go to a quarantine with clear reasons. Finally I return accepted and rejected counts and reconcile totals, with an explicit policy for partial acceptance versus rejecting the entire file.

I use BackgroundService as a hosting mechanism, not as a guarantee of durable scheduling. In-memory timers and progress disappear on restart, and multiple application replicas may start the same job. Depending on the requirement, I use a scheduler or durable job store and define overlap protection, retry policy, missed-run behavior and time-zone rules. The job itself remains idempotent and checkpointed, because even a durable scheduler can deliver work more than once after failures.

I design rollback before routing production traffic. The old application must still understand data written by the new version, so I use compatible schema changes and delay destructive cleanup. I define one writer for each business operation and verify authentication and session behavior through the proxy. If metrics or business checks regress, I can route the slice back while preserving completed writes. For irreversible changes, I need a recovery or compensation plan rather than pretending a route switch reverses them.

I first identify which operations actually require ordering, usually changes for the same order rather than every message globally. I use an entity key and version to detect stale updates or gaps, and define whether a failure blocks later changes for that entity. Transient failures get bounded retries; invalid payloads or mapping failures are quarantined with diagnostics and an owner. After fixing the cause, replay uses the original identifiers so recovery does not create duplicate business effects.