Why consolidating API gateways after a merger is different
Consolidating two API estates after a merger means moving partners, internal consumers and two identity providers onto one gateway, usually under a deadline set by integration plans and the acquirer's audit calendar. The practical answer is to consolidate onto one self-hosted gateway, such as Apache APISIX or Kong, with Keycloak or another OpenID Connect provider as the identity anchor, and to sequence the work so that partner-facing endpoints keep their hostnames, paths and credentials until each partner has been tested and told when the change happens. The sequence matters more than the product choice.
This differs from a greenfield gateway in three ways. First, the old estate is rarely fully documented, so the first deliverable is an inventory of routes, upstreams, consumers, keys, certificates and the plugins each route depends on, built from gateway configuration exports, access logs and DNS records rather than from wiki pages. Second, acquired-entity controls may need attention for financial reporting. SEC staff allow management to exclude a newly acquired business from its internal control assessment for a limited period, not beyond one year from the acquisition date and not from more than one annual report, and the exclusion must be disclosed. Confirm with your auditors which IT general controls around the old gateway still matter for financial reporting during that window. Third, traffic and logs may cross borders during the transition. Remote access to EU personal data from a third country, including support access, is a transfer under EDPB Guidelines 05/2021, so an acquirer's engineers outside the EEA need an approved transfer mechanism before they touch the target's gateway.
On platforms, Apache APISIX fits best when plugin flexibility and decoupled deployment matter, since its decoupled mode separates the data plane from a control plane sharing one etcd cluster. Kong fits when the team already runs it and has the operating skills. The choice should follow the inventory, not precede it: the plugins your routes actually use, the consumer model and the number of routes will determine whether either product needs custom work. Ask each candidate partner to show how existing authentication flows map to the chosen gateway before you commit to a migration plan.
Which obligations shape the consolidation plan
This table maps each regulatory or contractual obligation that touches a gateway merger to the evidence it demands and the build decision it forces. Read it as a checklist for scoping: any row that applies to your organization becomes a requirement in the migration plan before cutover work starts.
| Obligation | What it asks for | Build implication for the merged gateway |
|---|---|---|
| SEC ICFR exclusion of an acquired business | Management may exclude a newly acquired business from its internal control assessment for up to one year, must disclose the exclusion and its significance, and cannot stretch it beyond one annual report | Keep IT general control evidence for both gateways through the exclusion window so the migrated routes stay in scope when the exclusion ends |
| SEC Release 33-8810 IT general control areas | Program changes and access to programs and data are named as IT general control areas that matter where they affect financial reporting | Put gateway configuration under change control with approvals, and log administrative access to the Admin API and control plane |
| Form 8-K Item 1.05 and 17 CFR 229.106 (SEC registrants) | Material cybersecurity incidents require a prompt 8-K filing, and annual reports must describe oversight of third-party service provider risk | Define one incident path covering both estates during cutover, including partner-facing APIs and any vendor that operates either gateway |
| NIS2 Article 3(4) entity information | Entities must give their competent authority contact details, IP ranges, sector and service countries, and report changes without delay and within two weeks | Assign an owner to update the authority record whenever a merger changes IP ranges, gateway endpoints or the legal entity running the APIs |
| DORA Article 28(3) and 28(8) (EU financial entities) | A register must cover all ICT service arrangements, and tested exit strategies and transition plans are required for services supporting critical or important functions | Record the old gateway as an ICT arrangement with a documented retirement plan, a tested rollback and a transition timeline agreed with the business owner |
| EU Data Act Articles 23, 25 and 29 (switching) | Providers of data processing services must support switching to another provider or on-premises infrastructure, with no switching charges from 12 January 2027 | Applies where the old gateway is a provider's managed service: confirm exit terms, exportable configuration and any switching fees in writing before migration |
| EDPB Guidelines 05/2021 and GDPR Article 28(3)(a) | Remote access to EU personal data from a third country is a transfer requiring a Chapter V tool, and processors act only on documented instructions | Limit a non-EEA acquirer's staff access to the target gateway, use an approved transfer tool, and document instructions for any processing of logs or payloads |
| 45 CFR 164.314(a) (HIPAA business associates) | Business associate contracts must require Security Rule compliance, flow terms down to subcontractors handling ePHI, and report security incidents to the covered entity | Confirm which gateway paths carry ePHI, update subcontractor terms for the merged estate, and route security incident reports to each covered entity |
| PCI SSC FAQ 1004 and 1220 (cardholder data paths) | Payment brands, not PCI SSC, decide which entities must validate, and validation is documented on official PCI SSC templates with an attestation | Ask the payment brands or acquirer which entities and paths must validate after cardholder data routes merge, then plan the evidence for that scope |
How to inventory APIs nobody documented
The starting inventory for a merged estate is not the wiki. Undocumented APIs are usually the ones that matter most, so build the list from evidence: gateway access logs on both sides, DNS records and zone files, load balancer and ingress rules, and the target's Git repositories where route definitions, OpenAPI files and service manifests live. Each source reveals a different slice. Access logs show what is called and by whom, DNS and load balancer rules show what is exposed, and repositories show what was built but may no longer run. Reconcile the sources into one list and mark each hostname or path as confirmed, unused or unknown.
If the target runs Apache APISIX or Kong, export its route configuration first. For APISIX, the Admin API or the configuration file in standalone mode gives every route, upstream and plugin as structured data, which can be stored in Git and diffed against the acquirer's gateway. For Kong, the declarative configuration export does the same job. That export becomes the first consistent catalog. Add a row for each API with tags for owner, partner, data class and whether it touches payment or health data. Those last two tags decide which later controls apply, so set them deliberately rather than inheriting defaults.
This inventory sets the scope of every later step: identity mapping, route migration, partner communication and retirement. Treat it as incomplete by design. A gateway only sees traffic that passes through it, so services reached directly, batch jobs, and internal calls that bypass the edge will not appear in logs. Ask both engineering teams to confirm each API's owner and each partner dependency in writing before any cutover, and record that confirmation alongside the catalog entry. An API without a named owner and a confirmed consumer is not ready to move.
Mapping two identity providers onto one gateway
This option keeps both existing identity providers in place and places Keycloak between them and the gateway. Keycloak brokers each upstream provider, so users keep their home directory while the gateway trusts one issuer. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so an older SAML-based provider can be brokered alongside an OIDC provider. The APISIX openid-connect plugin points at the Keycloak realm, validates tokens against its published keys, and supports the authorization code flow with PKCE for user-facing applications and the client credentials flow for service clients.
- Token validation: Configure the openid-connect plugin with the realm discovery URL so the gateway fetches signing keys and checks issuer, audience and expiry on every request.
- PKCE and client credentials: Require PKCE for browser and mobile clients, and issue client credentials only to machine clients and approved partner integrations.
- Token lifetimes: Keep access tokens short and set session and refresh lifetimes per client type, since brokered sessions inherit the policy of the realm that issued them.
- Claim mapping: Map each upstream provider's attributes, such as department or partner identifier, to one set of claims the gateway's authorization rules read.
- Operator and database: Keycloak needs a supported production database and a synchronously replicated setup for high availability, and the Operator should use manual approval mode for updates.
Before cutover, confirm which upstream identities can be matched to one person and which accounts must stay separate, because brokering alone does not merge duplicate accounts.
This option moves all users from both identity providers into a single Keycloak realm, so the gateway, applications and partners see one source of identity. It removes the brokering layer and simplifies token validation, but it requires identity matching, password or credential migration decisions and a planned cutover for every application that signs users in. Keycloak can run user federation during the transition, which lets users keep authenticating against the source directory while the realm is populated. The gateway configuration then stays simple: one issuer, one set of client registrations and one claim model.
- Identity matching: Decide how duplicate employees, contractors and customers are merged, and who approves each match before any account is created.
- Client re-registration: Each application and partner client needs a new or updated client definition in the realm, with redirect URIs and PKCE settings reviewed.
- Token lifetimes: Align access and refresh lifetimes across both former estates so no user gets a longer session than policy allows.
- Schema and upgrades: Keycloak migrates its database schema at startup by default, but large deployments can apply the SQL manually; test the migration path on a copy first.
- Access review: Re-certify roles and group memberships after migration, since merged users often carry privileges from both former companies.
Confirm the target database engine and HA design with your platform team before migration, and ask the partner to document the rollback path if federation must be restored.
This option keeps partner clients on their existing identity provider and moves internal staff to Keycloak first. It suits a merger where partners have contractual or technical dependencies on the acquired company's provider and cannot change their integration on the merger timeline. The gateway then validates two issuers: Keycloak for staff, and the existing provider for partner tokens. The openid-connect plugin can be configured per route, so each API group trusts only the issuer that applies to its consumers. Staff-facing internal APIs gain one identity model early, while partner-facing routes keep their current behavior.
- Per-route issuers: Bind each route or route group to one issuer and audience so a token from one population cannot reach another population's APIs.
- Client credentials for partners: Confirm which partner integrations use client credentials and whether their token lifetimes and scopes match the new policy.
- Claim normalization: Where partner tokens and staff tokens carry different claims, normalize them in the gateway or in the APIs rather than assuming one shape.
- Staged staff move: Migrate staff applications in waves, keeping a fallback route to the old provider until each wave is verified.
- Access review scope: Certify staff access in Keycloak and certify partner client scopes separately, since the two populations have different owners.
Ask the partner to list every partner client, its grant type and its token lifetime before routing changes, and set a dated review of the partner-side provider so the split does not become permanent by default.
Migrating routes and plugins without breaking partners
This sequence moves partner and internal traffic from the acquired gateway to the surviving gateway in controlled steps, with a parity check, partner sign-off and a tested rollback at every stage. Each step ends with a written output the integration owner and the partner can review before traffic moves.
Freeze the configuration baseline in Git
Export every route, upstream, consumer, plugin and certificate from the retiring gateway and store them in a version-controlled repository before any change is made. Platform engineering and the gateway owner review the export against the API inventory from the earlier discovery work. The step is complete when a second person can rebuild the source gateway's routing from the repository alone and the diff against the live configuration is empty.
Choose the target deployment mode for configuration
Select how the surviving APISIX estate will hold configuration. Traditional mode keeps the data and control planes together, decoupled mode separates them while sharing one etcd cluster, and standalone mode drops etcd entirely and reads a YAML or JSON file or an API. In file-driven standalone mode, APISIX checks conf/apisix.yaml or conf/apisix.json every second and hot-reloads changes, which suits config-as-code in Git. The architecture owner signs off the choice, and the output is a decision record that names the mode, the reload path and who may merge configuration changes.
Translate plugins and document behavior differences
Map each plugin on the old gateway to its equivalent on the target, and list every case where the behavior differs, such as authentication flows, header handling, retry rules, error response bodies or how rate limit keys are derived. Custom plugins are rewritten or ported, and the team confirms the target supports each required capability instead of assuming parity. The output is a plugin translation register with one row per plugin, the chosen replacement and any partner-visible change, reviewed by the security architect.
Run both gateways behind one hostname
Publish the same hostname or DNS record in front of both gateways, using weighted or header-based routing so that traffic can shift without partners changing endpoints or certificates. Mirror a copy of production requests to the target gateway, discarding its responses, so that its behavior is observed under real load. Operations confirms the routing change can be reverted by a single DNS or load balancer edit. The output is a tested rollback runbook and a traffic map showing which routes are mirrored and which are live.
Produce a route-by-route parity report
Compare responses, status codes, latency and headers from the mirrored traffic against the source gateway, route by route. Differences are classified as expected (for example, a documented plugin change) or defective, and defects are fixed in the repository before the next stage. Rate limit counters are reviewed separately, because counters held in memory or in a shared store will reset when traffic moves, which can briefly admit more requests than the agreed plan allows. The output is a parity report signed by the integration lead for every route in scope.
Obtain partner sign-off per endpoint
Send each external partner the endpoints they use, the expected changes from the translation register, and the date window for their cutover in writing. Partners test against the target through a staging hostname or a scoped test consumer, and each one approves its own endpoints. Partners whose contracts require notice of changes to their integration are identified by the legal team before this step begins. The output is a signed sign-off record per partner and endpoint, with any open exceptions listed.
Shift partners one at a time with rollback
Move traffic partner by partner, starting with the lowest-risk integrations and ending with the most critical ones, while keeping the old gateway live for the whole window. After each shift, error rates, latency and authentication failures are checked against the baseline before the next partner moves. The rollback path is exercised on a live partner before the broad cutover, so the team knows it works under real traffic. The output is a shift log with a timestamp, a success check and a rollback result for each partner.
Freeze changes during the cutover window
Suspend routine changes to both gateways, identity configuration and the DNS records involved for the agreed window, and route any emergency change through a named approver. Only the cutover runbook is executed during this period, and the on-call team monitors partner error budgets continuously. The freeze ends after the final partner is confirmed healthy and the old gateway has served no production traffic for the agreed observation period. The output is a closed change record and a handover note to operations.
Which open-source gateways and identity components fit a merger
A merger usually leaves two gateways and two identity providers in place, and the consolidation target has to work for both estates. The options below differ in license, deployment model and how well they fit the gateway and identity systems the combined company already runs.
Apache APISIX as the consolidation target
APISIX is licensed under Apache-2.0 and its 3.19.0 release came out on September 28, 2026. It ships more than 100 built-in plugins, which helps when the acquired estate relies on a mix of authentication, traffic control and observability features. Traditional, decoupled and standalone deployment modes let you match the topology to each side's network and change process. Confirm plugin parity with the legacy gateway for every policy that partners depend on, such as rate limits per consumer and custom authentication, before any route moves.
Kong Gateway where Kong already runs
Kong Gateway is licensed under Apache-2.0 and 3.9.4 was published on October 12, 2026. If the acquiring or acquired team already operates Kong, keeping Kong as the target avoids retraining operators and rewriting plugin configuration on that side. The decision depends on which estate carries more partner traffic and on the plugins each side uses. Ask the implementation partner to produce a plugin-by-plugin comparison and confirm that the features your partners rely on are available in the open-source edition you plan to run.
Keycloak to map two identity providers
Keycloak is licensed under Apache 2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0. Its identity brokering and user federation features let you keep both legacy identity providers during the transition while issuing one set of tokens to the gateway. The current release is 26.8.1, published October 13, 2026. Production deployments need a supported database such as PostgreSQL 14 to 18, and a synchronously replicated database for high availability. Confirm how each acquired directory's groups and claims map to the scopes your APIs check.
APISIX Ingress Controller for Kubernetes estates
If either side hosts its APIs on Kubernetes, the APISIX Ingress Controller lets you manage gateway routes through Kubernetes resources, which suits teams that already keep their manifests in Git. Version 2.2.0 was released on August 18, 2026. Confirm which controller version matches your target APISIX version, because the two must be upgraded together. Check how routes from the acquired cluster will be imported, and whether the controller's resource model covers every route type your partners use, including gRPC and WebSocket.
Evidence auditors and regulators will ask for
This table lists each piece of evidence an assessor is likely to request after a gateway merger, the component or record that produces it, and the question it answers. Confirm the exact list with your external auditor or regulator before cutover work begins, because the applicable regime (SEC internal control reporting, DORA, NIS2, GDPR, HIPAA or PCI DSS) changes what is required. Treat the rows as a starting point for scoping, not a final checklist.
| Evidence | Produced by | Question it answers |
|---|---|---|
| API inventory export with owners and data classes | Gateway route export reconciled against the CMDB | Which APIs existed on both estates, who owns each one, and what data classes they carry? |
| Change records for each route and plugin move | Git history, pull requests and approval records | Who approved each route or plugin migration, and can each change be traced to a reviewed commit? |
| Access reviews for admin accounts and identity mappings | Keycloak admin events and exported review records | Which administrators can change gateway or identity configuration, and was their access reviewed after the merger? |
| Cutover test results and rollback proof | Test reports from staging and production cutover runs | Did partner traffic behave as expected after each migration wave, and was rollback tested before it was needed? |
| Register entry and exit plan for the retired gateway | Vendor and ICT third-party register, exit strategy document | Is the old gateway recorded in the register, and is there a tested plan to exit or transition the service? |
| Processor instruction records for acquirer staff remote access | GDPR Article 28 instructions and transfer tool records | Who from the acquirer accessed EU personal data, under which documented instructions, and under which transfer mechanism? |
| Gateway access audit logs retained for the required period | Gateway access logs shipped to self-hosted log storage | Can access to partner and personal data be reconstructed for the retention period the applicable regime requires? |
Questions buyers ask before consolidating gateways
How much does it cost to consolidate two API gateways after a merger?
The cost depends on the written scope, and DeployOpen does not publish a price list, so a quote follows from that scope. The main cost components are the discovery work to inventory undocumented APIs, the identity mapping between two identity providers, plugin parity work for every policy the old gateway enforces, partner migration and testing, the target infrastructure, and the period when both gateways run. Inventory volume, the number of identity providers and authentication flows, the number of partners with their own integration tests, and the count of custom plugins or scripts drive the figure most. Ask each bidder to price these components separately, state which are one-time and which recur (infrastructure, licenses or support retainers, and upgrades), and list the assumptions about change windows and partner testing.
How long does a gateway consolidation take?
The timeline is set by how much of the estate is known, how many partners must test, and how many change windows the business allows, not by the gateway software alone. Discovery usually takes the longest when APIs are undocumented, because each unknown route must be found, owned and classified before it can move. Identity mapping and partner cutovers follow, and the old gateway can only be retired after traffic has moved and the dual-run period has closed. Ask for a phased plan with milestones, the entry and exit criteria for each phase, and the dates your partners have agreed to test. Any duration in a proposal should trace back to the inventory results and the agreed scope.
What does the internal team need to provide during a gateway consolidation?
The internal team must name owners for every API, identity provider and partner integration, and must give the outside partner direct contacts on each side of the merger. Owners decide whether an undocumented route is still in use, approve its retirement, and sign off on behavior changes. The team also needs change windows that both legacy estates can use, access to current gateway configuration and logs, and a named approver for cutover and rollback decisions. Partner contacts should be able to run integration tests on a schedule. Confirm these responsibilities in the statement of work so that a missing owner does not become an unplanned delay.
Can our own team consolidate the gateways without an outside partner?
Yes, an experienced platform team can consolidate gateways without an outside partner if it has the time, the skills and the capacity to run discovery, identity mapping, plugin migration and partner testing in parallel. The open-source gateways involved, such as Apache APISIX and Kong Gateway, are self-hosted, so the team must also operate the data and control planes, upgrades and backups. Teams that choose to bring in a partner usually do so for the inventory sprint, the identity work or the cutover support, and sometimes for ongoing operations. Assess your team against each phase, and check whether the people who know the legacy estate will still be available after the close.
What happens to partner integrations while both gateways run?
During dual-run, each partner should keep calling the gateway it already uses, and routes should move only after that partner has passed its own tests on the new gateway. Typical controls include mirroring read-only traffic to the new gateway for comparison, moving low-risk routes first, keeping the same hostnames or documenting the change, and keeping the legacy route ready for rollback. Partner credentials, rate limits and token formats must match, or the partner must receive a dated migration notice. Plan partner communications early and agree a rollback decision rule for each cutover. Confirm with each partner whether its contract or onboarding document names the gateway, because changing the endpoint may require a contract notice.
Can we retire the old gateway before the ICFR exclusion period ends?
The SEC staff guidance allows management to exclude a newly acquired business from its internal control over financial reporting assessment, but the exclusion cannot extend beyond one year from the acquisition date or cover more than one annual report. That limit applies only to ICFR scope, so it does not require the old gateway to stay in service for one year. Retiring the gateway earlier is a technical and risk decision, provided that the financial reporting controls and IT general controls that depend on it are covered, that access and change records are kept, and that any excluded business and its significance are disclosed. Ask your external auditor to confirm how the retirement affects the controls in scope, and record the decision and its evidence before shutdown.
How do we give an acquirer's staff access to EU API systems?
Remote access from a third country to EU personal data, including for support or administration, counts as a transfer under EDPB Guidelines 05/2021, so the acquirer's staff need a Chapter V transfer tool before they can view personal data in EU systems. Start by limiting access to the gateway configuration, which often contains no personal data, and separate it from logs and payloads that do. Use named accounts, least privilege and time-limited access, and document the processing instructions under GDPR Article 28. Confirm with your data protection officer and legal counsel which transfer mechanism applies and whether any other rules, such as NIS2 notification of changes, apply to the entity.
What to ask an implementation partner about gateway consolidation
Start with the inventory, because every later step depends on it. Ask how the partner builds the list of routes, upstreams, consumers and plugins from live traffic and gateway configuration, not from the wiki or the architecture diagrams that the two companies bring to the deal. Ask which log sources they will use (access logs from both gateways, DNS and load balancer records, and API calls from partner systems), how long that window is, and how they will flag APIs that receive traffic but have no owner. Ask for the exported configuration from both estates, the method used to diff them, and a written list of the APIs that are still unexplained at the end of discovery. Confirm that the partner will not start migration until that list has an owner for each entry.
Ask how they will map the two identity providers before any route moves. A common anchor is Keycloak or another OpenID Connect provider that both estates can federate to, and the partner should explain how the openid-connect plugin in Apache APISIX or the equivalent in Kong will validate tokens from each source. Ask them to show the claim mapping for sub, aud, scope, and any tenant or group claim, and to test those claims with real tokens from each identity provider, including expired, revoked and out-of-scope tokens. Ask who approves changes to realms, client registrations and redirect URIs, and whether the partner will document which application relied on which identity provider on the day of cutover.
Ask how cutover is run partner by partner. A safe pattern is to send a small share of each partner's traffic to the new gateway while the old one stays live, compare responses and error rates, then move the rest. Ask for the written rollback criteria, the person who can trigger rollback, and how long the old route stays ready to take traffic. Ask how the partner will keep configuration in Git, who reviews each change, and how production changes are approved and recorded. Then ask how staff in another jurisdiction will reach the systems. If engineers outside the EEA can see personal data during support, the partner should explain which transfer mechanism applies, and under which DORA or HIPAA contract terms the work is covered (confirm these with counsel). Finally, ask how they will produce the decommissioning evidence for the old gateway: the configuration snapshot, the access log retention, the decommission record, and the list of who held admin credentials. Ask who holds the Admin API keys and etcd access after handover, and whether those credentials are rotated and stored in the client's own vault.
Rollout phases and what each produces
The sequence moves from knowing what exists, to agreeing who signs in, to proving the target gateway behaves like the old one, to moving partners in waves and retiring the old gateway with a record of what was removed. Each phase closes with a written output that the next phase depends on. Scope and timeline are agreed in writing before work starts.
Inventory every API and route
Discovery pulls route tables, gateway configuration, DNS and load balancer records, and traffic logs from both estates, then compares them with the API catalog and the owners each team names. Undocumented APIs, shadow endpoints, and partner-specific routes are flagged with an owner, a consumer list, and a traffic profile. The output is the inventory register, and the step is done when each route is either assigned to an owner with a migration disposition or marked for retirement with that owner's sign-off.
Design identity mapping across providers
Each identity provider in the acquired estate is mapped to the target realm, covering user sources, client registrations, token lifetimes, scopes, claims, and the authentication flows each partner uses. The team decides whether the target broker federates the legacy provider during transition or whether clients are re-registered. Security, identity, and legal owners review the design before build. The output is the identity design record, and it is complete when every client and scope in the inventory maps to a documented target.
Build and harden the target gateway
The target gateway is built from configuration kept in version control, with the plugins the inventory requires, the chosen identity integration, logging and metrics routed to the organization's own storage, and the deployment mode agreed in discovery. Hardening covers admin API exposure, TLS policy, and rate limits. Testing covers functional, security, and load checks against staging routes. The output is a tested target gateway, and the step closes when the test results and configuration baseline are signed off.
Run parity tests with a pilot partner
One willing partner or low-risk internal consumer is routed through both gateways in parallel. Responses, status codes, headers, error bodies, latency, authentication outcomes, and rate-limit behavior are compared for identical requests. Differences are logged and either fixed in the target or accepted in writing by the partner. The output is a parity report. The step is done when the pilot runs without unexplained differences for the agreed observation period and the partner confirms the behavior it depends on.
Migrate partners in controlled waves
Routes move in groups defined by risk, partner, and dependency, each with a documented rollback path that returns traffic to the legacy gateway. Partner notices, credential or client changes, and cutover windows are agreed before each wave. Changes are recorded as they happen, including who approved them, which routes moved, and whether rollback was used. The output is a cutover log for each wave. Waves continue only after the previous wave's error and partner-impact review is closed.
Retire the legacy gateway with exit evidence
Once all routes are confirmed on the target, traffic is observed on the legacy gateway until it is quiet, then configuration, certificates, credentials, and data stores are archived or deleted according to the retention rules agreed with the client. Decommissioning covers DNS, firewall rules, monitoring, and backups. The output is a retirement and exit record listing removed components, retained logs, and the owner who accepted closure. The step closes when that record is signed and filed with the compliance evidence set.
How DeployOpen scopes and runs a gateway consolidation
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source API gateways and identity services inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a consolidation, that usually means one target gateway (for example, Apache APISIX or Kong Gateway), one identity layer (for example, Keycloak), and the migration tooling and runbooks needed to move both estates onto them. The first decision is which gateway deployment mode the target will use. Apache APISIX supports traditional, decoupled and standalone modes, and the choice affects where the Admin API listens (port 9180 in traditional mode), how configuration is versioned, and who can change routes. That decision belongs in the written scope, not in the migration sprint.
Most engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and that document should name the APIs in and out of the migration wave, the partners who must be notified, the identity provider mappings, the cutover criteria and the date on which the legacy gateway is switched off. Changes after signature go through a written change request. Security testing of the migrated APIs can be included in the scope, and so can rehearsal of the cutover and rollback steps in a private cyber range before any partner traffic moves. DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration exports, access reviews and change records, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so the reader should confirm early which assessor will review the consolidation and what evidence that assessor expects.
Ongoing support, gateway upgrades and continuous testing run on retainers, which matter because a consolidation rarely ends at cutover. Legacy routes are often retired in waves over months, and the new gateway will need patching and version upgrades while partners are still connecting. Before signing, ask the partner how it will handle upgrade approval, how configuration is kept in version control, and how it will test rollback during the retirement period. Ask for the written scope to state who owns each artifact after handover, including the route inventory, plugin configuration, identity client definitions and runbooks, so that the merged organization can operate the platform without depending on the implementer.
