---
title: "Case study: SEEBURGER BIS 5 to IBM Sterling for ÖBB"
description: "KONDEVS led business analysis and requirements management for moving a whole SEEBURGER BIS 5 application, every interface and API, to IBM Sterling at ÖBB."
canonical: "https://www.kondevs.com/case-studies/"
language: "en"
type: "website"
image: "https://www.kondevs.com/images/og-default.png"
---

> For the complete index of this site, see [llms.txt](https://www.kondevs.com/llms.txt); the whole site in one file: [llms-full.txt](https://www.kondevs.com/llms-full.txt).

# Case studies

Projects we can describe in public: what was moved, on which platforms, and what KONDEVS was responsible for.

Railways · Austria · 2019-2021

## ÖBB: a whole SEEBURGER BIS 5 application moved to IBM Sterling

| Client | Austrian Federal Railways (ÖBB), Vienna |
| --- | --- |
| Period | 2019-2021, two years |
| Our role | Business analysis and requirements management, one consultant from KONDEVS |
| Scope | The whole application: every module, every interface and API |
| Platforms | From SEEBURGER BIS 5 to IBM Sterling |

### The task

ÖBB moved an integration application from SEEBURGER BIS 5 to IBM Sterling. It was not a pilot or a first wave: the migration covered every module of the SEEBURGER installation, with all of its interfaces and APIs.

### What KONDEVS did

For two years KONDEVS held the business analysis and the requirements management of the migration. The work turns a running application into requirements for the target platform: what each module and each interface does today, what it has to do on IBM Sterling, and how anyone can check that it does.

KONDEVS did this with one consultant, who worked with the client's teams for the whole migration.

### Result

The whole application, every interface and every API, was migrated from SEEBURGER BIS 5 to IBM Sterling.

## How we approach a SEEBURGER to IBM Sterling migration

What we bring to a move between integration platforms, in the order we work:

1. ### Inventory before target.

A SEEBURGER installation that has run for years holds more than its documentation: mappings, partner-specific rules, schedules and error handling. Each of them is a requirement until it is shown to be obsolete.

2. ### Behaviour, not configuration.

SEEBURGER and IBM Sterling model processes, mappings and partner profiles differently, so a one-to-one copy of settings rarely works. A requirement states what an interface receives, transforms and delivers, and when it has to stop or retry; the implementation team decides how IBM Sterling does it.

3. ### Every requirement testable.

For each interface: sample messages, the expected result and an acceptance criterion. A migration is done when the new platform gives the same results as the old one, not when its configuration is complete.

4. ### APIs and file flows in one inventory.

Synchronous APIs and asynchronous file or EDI flows share partners and data. Kept in separate lists, they hide the dependencies that decide the order of the cutover.