How to Prepare Your Systems for an Integration Project

Need a partner to connect the systems?

Explore LCR’s systems integration and workflow service to agree the system map, ownership decisions, exception handling and first pilot. Specific interfaces and delivery scope need verification before committing to the build.

Write down the transaction contract

For each record or action, capture its identifier, required fields, allowed values, owner and expected result. Explain units, time zones, status meanings and how corrected or deleted records are represented. Include the refresh requirement and the consequence of delayed information.

• Which system may create or change the authoritative record?
• How is the same entity recognised in both systems?
• What constitutes acceptance, rejection or work still pending?
• What prevents a retry from creating an unintended duplicate?
• Who resolves mismatches rather than silently overwriting them?

A successful connection test answers only whether access works. It does not prove that both teams interpret the exchanged data in the same way.

Prepare controlled access and representative data

Agree separate test access, the minimum permissions needed and how credentials are issued, stored, rotated and revoked. Do not paste production secrets into a brief or shared sample file. Ask the system owner what can safely be exercised in a sandbox and where its behaviour differs from production.

OWASP's REST security guidance calls for HTTPS and endpoint access control, and warns against putting credentials in URLs. Those controls are part of the preparation, not a substitute for reviewing the complete integration.

Use synthetic or appropriately sanitised records that preserve important edge cases. Agree authorised access, retention and deletion for any necessary real data. Include missing values, historical statuses and corrected identifiers, not only a perfect demonstration record.

Agree failure behaviour before the first write

Ask what happens when a request times out after the receiving system has accepted it. Define a way to check the existing outcome before repeating a consequential operation. Also plan for unavailable dependencies, permission expiry, rate limits and records that fail validation.

Hypothetical example: a portal submits a service request to an operational system. The response is lost. Staff should be able to find the original request by its correlation reference before deciding whether it needs resubmission. A timeout should not automatically create another job.

Record the recovery owner, visibility needed in logs and the conditions for manual intervention. Keep sensitive payloads out of routine diagnostic messages unless their storage is necessary, authorised and protected.

Use a readiness decision, not a completed checklist alone

Before build planning, review the available evidence: a named owner, confirmed operation, test access, representative records and an agreed failure path. Identify what is proven, what remains assumed and the next test needed. If access is unavailable, estimate that uncertainty explicitly rather than hiding it.

Pilot the smallest complete transaction. Reconcile what was sent, accepted and applied, then check the business result with the owner. Agree how release changes are controlled and how a failed cutover is recovered.

Bring the evidence to a discovery discussion and include dependencies in the delivery scope. Price and timing should follow the verified work, not the number of systems in a diagram.

Questions

Frequently asked questions