Skip to content
PI Square
Book

Modernisation and integration

Old systems mapped and documented by AI, rebuilt one slice at a time, and proved against the original before anything switches.

deaddeadthe old order systembatch jobscode mapr12 list less tierokr13 half-cent down?r14 vat lastokrule bookgolden masterslockedold dbpricingnew servicenew dbin syncfacadeshadowold104.37new104.381 diffai: rounding, rule r13a person decidesside by side · differences
  1. 1Map the code
  2. 2Extract the rules
  3. 3Pin the behaviour
  4. 4Slice
  5. 5Rebuild
  6. 6Side by side
  7. 7Shift traffic
  8. 8Retire
Try it

Modernisation with AI works when AI reads and people decide. PI Square uses AI agents to map an old system and write its business rules in plain words, each linked to the lines it came from, and your people confirm them. The old system's behaviour is recorded as locked tests before anything changes. Then one slice at a time is rebuilt from the confirmed rules, run side by side with the original on real traffic until the two agree, and switched over with both databases kept in sync.

  1. The system you run today

    Oracle, SAP, Java, COBOL, spreadsheets

  2. Your cloud

    Mapped, and its rules written

    by AI, confirmed by your people

  3. Rebuilt one slice at a time

    from the rules, not the old code

  4. Proved against the original

    locked tests, then side by side on real traffic

  5. Switched over, then retired

    a routing change, with data kept in sync

What it's for

  • Retail and distribution

    Pricing, promotions or stock logic moved out of an old order system, one module at a time.

  • Financial services

    Interest, fee and statement logic documented and rebuilt, with every rounding rule kept.

  • Manufacturing and supply chain

    Planning and integration jobs moved off a single large application onto events every system can use.

  • Any business with an old core system

    A map of the system and a rule book of its business rules, even before you decide to migrate.

How we keep it safe

  • Your people confirm the rules before any new code is written; the rule book is the specification.
  • Golden masters are recorded on the untouched system and locked, so the AI writing new code can't change them.
  • Old and new run side by side on real traffic, and a person decides every difference.
  • Traffic moves in steps, both databases stay in sync, and rolling back is one routing change.
  • Every new function links to the rule it implements and the old lines it replaces.

Built with

  • Java and Spring Boot
  • TypeScript and Node.js
  • Python
  • Oracle EBS, ADF and Fusion
  • SAP S/4HANA
  • RabbitMQ and Pub/Sub
  • Change data capture
  • Cloud providers' modernisation tooling

Where we've built this

  • A global pharmaceutical company: integration architecture for finance systems across Oracle EBS and SAP S/4HANA, with a team of seven in the US and India.
  • Two brands in a southern African retail group: one event-driven platform in place of point-to-point links between more than 20 retail, logistics and e-commerce systems.
  • A retail group with more than 1,000 stores: core retail applications, built and run over seven years.

How an engagement runs

  1. Understand

    We map your system and write its rule book with AI, confirmed by your people, and mark the dead code and the first slice worth moving. The map and the rule book are yours either way.

  2. Prove

    One slice rebuilt from the rules, pinned by golden masters, and run side by side with the original until the two agree.

  3. Embed

    Your team takes ownership of the rebuilt slice and its operating guide. Further slices are separate decisions; the original system stays in place wherever it is still needed.

The full approach

Questions about modernisation and integration

Will you translate our old code line by line?
No. Line-by-line translation copies the old system's structure into a new language, and the hidden rules break in production. We use AI to extract the business rules first, your people confirm them, and the new code is written from those rules.
How do you prove the new system behaves the same?
Before anything changes, we record the old system's outputs for real inputs as golden masters and lock them, and the new code has to reproduce them. Then both systems run side by side on live traffic, including a month-end or year-end replay, and every difference is explained and decided before traffic moves.
What do we get from Assess?
A map of your system, showing what calls what and which code no longer runs, and a rule book of its business rules in plain words, each linked to the code it came from and confirmed by your people. Both are useful even if you decide not to migrate.
Do we need to modernise before we use AI?
Not always. Many AI systems can read from what you run today. We recommend modernising only the parts that block the AI work you want, and we name them during Understand.
Which platforms and tools do you work with?
Oracle EBS, ADF and Fusion, SAP S/4HANA, Java and Spring, Node.js and Python, with RabbitMQ or Pub/Sub for events, on Google Cloud, AWS or Azure. Where they fit, we use the cloud providers' own modernisation tooling alongside our own.
How do you keep data in sync while running old and new systems together?
Depending on the source systems, change data capture, events or scheduled synchronisation can keep data aligned. We test delays, reconciliation and recovery before cutover. Rollback depends on compatible schemas and data state as well as routing, so its limits are agreed and rehearsed.

The other five

Tell us what you're working on

Keep this general; leave out sensitive or confidential information.

Or email nikhil@pisquare.ai