It cannot be stopped,
so it never gets touched.

Core business processes running on Access, Excel, or a system built long ago. It works, but few people understand what is inside it, and when it stops there is no way to find out what happened. You want to replace it, but external connections mean you cannot move all of it. We take that stalled core and move it to the cloud, starting with what can move.

Pain points

Does any of this sound familiar?

Come to us at the stage where you want to replace it but cannot stop it.

Core processes run on Access or Excel, and only a handful of people understand them.
When processing stops, recovery is manual and nobody can trace what went wrong.
Connections to trading partners mean the system cannot be swapped out all at once.
The vendor who built it is no longer around, so nothing can be changed.
You want to move to the cloud but do not know where to start.
It is unclear who would look after it once it has moved.
Reasons

Why clients choose us

When the system cannot be stopped, being able to build is not enough. Reading what is there, moving it without interruption, and staying with it afterwards all have to come together.

A

We read the system itself

We assume no specification exists. We read the screens, queries, and macros, and write down what actually runs and how. You do not need someone who can explain the whole thing to us.

B

We move it without stopping it

Nothing rides on a single cutover day. Old and new run in parallel until their output matches, and only then do we switch. Because external connections can stay, trading partners are never involved.

C

We stay with it afterwards

The infrastructure is run as our own service, with monitoring and operation on our side. We do not hand it over and walk away; we stay responsible for it continuing to run.

D

We run our own products too

We do not only build for clients — we plan, build, and operate our own SaaS. We design knowing from experience what happens after release.

Scope

What we cover

One team handles everything from reading the existing system through migration planning, rebuilding, cutover, and ongoing operation. We do not sell the assessment or the build in isolation.

01 Assessment

Reading what exists

We read the existing system and write down the full picture of its functions and automated jobs. Starting to build while this is still vague guarantees trouble at the end of the migration.

  • Inventory of screens, reports, and data structures
  • Timeline of automated jobs and batches
  • Connections to external systems and trading partners
  • Operational pain points and past incidents
  • Putting the current business rules into words
02 Planning

Migration plan

What moves to the cloud and what stays is decided and agreed before implementation. That includes the decision not to replace everything at once; the order and scope are fixed here.

  • Drawing the line between what moves and what stays
  • Designing the hybrid setup
  • Deciding how historical data is treated
  • Cutover method and parallel-running period
  • Cost, timeline, and team
03 Rebuild

Rebuilding

Rather than copying the old screens, we rebuild around how the work is done now. Daily processing runs on the same platform as the application and retries automatically when it fails.

  • Web application development
  • Migrating scheduled jobs and batches
  • Roles and permissions
  • Operation logs and processing history
  • Cloud infrastructure defined as code
04 Migration

Data migration and cutover

Historical data carries over in full so that reporting stays continuous. The migration is built to be re-run from scratch, and the switch waits until old and new output match.

  • Full migration of historical data
  • Migration rehearsals
  • Parallel running and reconciliation
  • A written cutover procedure
  • A rollback plan
05 Operation

Operation after the move

The infrastructure stays with us. Monitoring, incident response, backups, and improvements continue on our side, so it works even without an in-house operations team.

  • Uptime and log monitoring
  • First-line incident response
  • Backups and documented recovery
  • Applying security updates
  • Ongoing improvements and new features
Process

How we work

We do not quote up front. We read the system first, decide what moves and how, and only then present cost and timeline.

  • 01Talk to us: tell us what is going wrong and roughly what is running. There is no charge at this stage.
  • 02Reading what exists: we read the system itself and write down the full picture. This is usually the first time it becomes visible.
  • 03The migration plan: scope, order, cost, and timeline, presented as a plan. Deciding not to proceed is a valid outcome here.
  • 04Rebuilding: we build the agreed scope, showing working software early so it can be checked against the actual work.
  • 05Parallel running and cutover: old and new run together, and we switch once their output matches.
  • 06Operation: we keep the infrastructure and continue monitoring and improving it. The parts left behind can move next, in the order already mapped out.
Comparison

Compared with the alternatives

There are several ways to replace an ageing core system, each with its own fit. If we judge that we are not the right fit, we will say so.

Off-the-shelf package

Fit the business to the product

  • Implementation cost is easy to predict
  • The business has to bend to the product
  • Industry practices and partner requirements often do not fit
  • Existing external connections usually have to be rebuilt
The original vendor

Ask whoever built it

  • They know the history
  • Staff turnover or withdrawal can leave you stranded
  • It can end up rebuilt the same way, just newer
  • Cloud operation is not always part of what they do
SHANNON

Cloud Lift

  • We assume no specification and read the system itself
  • External connections stay; the move happens in stages without stopping the business
  • Historical data carries over in full, keeping reporting continuous
  • Infrastructure operation and monitoring continue with us afterwards
  • We map out the order in which the remaining parts can move
FAQ

Frequently asked questions

Assume that is the normal case. Projects with a usable specification are the exception, so we start by reading the system and writing down the full picture.
That is fine. As long as you can give us the existing files and data, we can work from those.
No — and we advise against it. Leaving external connections in place and moving the self-contained parts first means your trading partners are never involved.
Old and new run in parallel and we switch only once their output matches. Nothing rides on stopping the business for a cutover day.
It carries over in full, as a rule. If continuity of reporting breaks, much of the point of the migration is lost.
The infrastructure is run as our own service, with monitoring, incident response, and improvements continuing on our side, so it works without an in-house operations team.
There is no charge for that stage. We will look at what you have and answer honestly, including if the answer is not to proceed.
Talk to us
Contact

Start by showing us what you have

We will look at the system itself and tell you what can move and what should stay. There is no charge for that stage.

You can also reach us by phone (050-1794-9651, automated voice; we call back on business days). For detailed enquiries with budget and timing, please use the contact form. Note: we do not accept sales solicitations.