- Home
- Services ▼
ServiceNow View all ServiceNow services →Other ServicesNot sure where to start? Talk to an expert →
- Industries ▼
- Resources ▼
- Company ▼
- Contact
Every enterprise has systems that are business-critical, decades old, and maintained by three people who are all close to retirement. They are not going away this year, and pretending otherwise is how modernisation programmes stall. Ramisun connects ServiceNow to legacy estates and existing middleware as they actually are — with honest advice about when to route through your iPaaS and when to go direct.
Legacy and middleware integration connects ServiceNow to systems that predate modern APIs — mainframes, AS/400 estates, legacy relational databases, message queues, file-based interfaces, and enterprise service buses — as well as to iPaaS platforms such as MuleSoft, Boomi, and Azure Integration Services that may already sit between them. The work is as much architectural judgement as engineering: deciding which connections should route through existing middleware, which should be direct, and which legacy interfaces are worth building against at all.
"The mainframe is not going anywhere this year. An integration strategy that assumes otherwise is a modernisation programme that stalls in month four."
AS/400, MQ, flat-file, and JDBC interfaces connected reliably.
MuleSoft, Boomi, Azure, and ESB estates used where they add real value.
Secure connectivity to on-premise systems without inbound firewall rules.
Vendor-neutral advice, because we do not sell an integration platform.
And why postponing it usually costs more than doing it.
Figures shown are industry benchmarks and illustrative placeholders — replace with sourced, dated statistics before publication.
Understand the constraint before choosing the pattern.
Interfaces, protocols, data volumes, and batch windows documented
Direct connection or existing middleware, assessed honestly
Connectivity pattern, MID Server placement, and error handling
Integration built with the legacy system's real constraints respected
Parallel run against existing process before any cutover
Runbook covering the failure modes the legacy system actually has
Legacy systems punish assumptions. We start by removing them.
| Area | ❌ Typical Approach | ✅ Ramisun Approach |
|---|---|---|
| Discovery | Assumed based on documentation nobody has updated | Interfaces surveyed empirically with the people who run them |
| Routing Decision | Everything through the iPaaS by policy | Direct or middleware assessed per integration on merit |
| Connectivity | Firewall exceptions requested for inbound access | MID Server outbound, usually no firewall change needed |
| Batch Windows | Ignored until the nightly job collides | Respected and designed around explicitly |
| Character Encoding | Discovered when data arrives corrupted | EBCDIC, code pages, and encoding handled up front |
| Cutover | Big-bang switch with a rollback nobody has tested | Parallel run and verified before switching |
| Knowledge | Held by two people close to retirement | Documented runbook with real failure modes |
Each capability maps to real delivery work — with outcomes and the Ramisun approach.
Mainframe integration is rarely elegant and usually entirely achievable. We work with whatever interface actually exists — MQ, flat file, JDBC, or a transaction gateway — and design around its real constraints rather than the ones we would prefer.
If you have already invested in an integration platform, the question is which ServiceNow integrations genuinely benefit from routing through it. We answer that honestly, because we do not sell an iPaaS and have no reason to over- or under-use yours.
MID Server is how ServiceNow reaches systems inside your network without anyone opening an inbound firewall rule. Designed well it is secure, resilient, and uncontroversial with security teams; designed badly it becomes a single point of failure.
A surprising share of enterprise integration is still a database view or a file on a schedule. That is fine when it is designed deliberately, with the transaction, locking, and volume behaviour understood.
Most enterprises cannot produce a current, accurate list of their integrations. Before recommending anything we survey what exists, what still runs, and what is quietly dead — which usually turns out to be a substantial fraction.
Legacy replacement programmes fail when they try to do everything at once. We use ServiceNow as an abstraction layer so legacy systems can be replaced behind a stable interface, one at a time, without a big-bang cutover.
Pragmatism about the estate you have, not the one a slide deck assumes.
Legacy documentation is almost always out of date. We establish what actually runs by talking to the people who operate it, which regularly reveals that a meaningful share of interfaces are dead.
We do not sell an integration platform, so we have no reason to route everything through yours or to bypass it. Each integration is assessed on whether the middleware adds real value.
MID Server establishes outbound connections from your network, so inbound firewall rules are rarely required. This is usually what makes the design acceptable to security teams.
Batch windows, locking behaviour, character encoding, and source system load are real constraints. Designing around them is cheaper than discovering them during a parallel run.
Legacy cutovers are verified, not trusted. We run the new integration alongside the existing process until the outputs match, then switch with a rollback path that has been tested.
The knowledge in these systems typically lives with a small number of long-serving people. Capturing the real failure modes in a runbook is often the most durable value of the engagement.
Tell us what you are working with, however unglamorous. We will tell you honestly what is achievable and what it will take.
"The mainframe is not going anywhere this year. An integration strategy that assumes otherwise stalls in month four."
Yes, though rarely through a modern REST API. In practice we use whatever interface exists — message queues, flat file exchange, JDBC against a database layer, or a transaction gateway. It is seldom elegant but it is usually entirely achievable, and it removes a great deal of manual re-keying.
It depends on the integration, and we assess each one on merit. Where your middleware provides genuine governance, transformation, or a canonical data model, routing through it is sensible. Where it would only add latency, cost, and another team's backlog to a simple two-system connection, direct is usually better. We sell no integration platform, so we have no stake in the answer.
Usually not. MID Server runs inside your network and establishes an outbound connection to your instance, so no inbound rule is required. This is the standard pattern for on-premise connectivity and is generally what makes it acceptable to security teams.
It is normal rather than exceptional. We survey empirically — talking to the people who operate the systems and observing what actually runs, rather than trusting a document nobody has updated. This regularly reveals that a substantial share of documented interfaces are no longer live, which is useful in itself.
That is usually the only approach that succeeds. Using ServiceNow as a stable abstraction layer lets you replace back-end systems one at a time behind an unchanged interface, with parallel running to verify each step. It avoids the big-bang cutover that causes most legacy programmes to stall.
Typically 6–12 weeks, with documentation quality as the main variable rather than technical complexity. Where interfaces are undocumented and the people who understand them are hard to reach, discovery takes longer than the build — and we scope that honestly rather than assuming.
Every quarter without the right platform is revenue and efficiency left on the table. Tell us your challenge — get a real plan back, not a sales script.
A ServiceNow consultant will reach out within one business day to schedule your session.