01
Data architecture for AI
Source inventory and their real state, a semantic model with shared definitions, access permissions and traceability: every answer knows where it came from.
Pillar 2 · Your data and systems
Connectable systems, queryable data.
This is the step almost nobody budgets, and the one that explains most stalled AI projects. It does not compete with AI for budget: it is its prerequisite. Modernisation runs on ARISE, our own framework.
Why this step always shows up late
The board asks for AI. IT knows that getting there means touching data spread across seven places and systems nobody wants to open, but has no way to explain it upwards. Modernisation waits for an incident.
When you move from «summarise this email» to «how much did we produce yesterday», the conversation changes. The information exists in Power BI, SAP and spreadsheets, but there is no direct way to ask it anything, and «production» means something different in each one.
1 in 2 generative AI projects drags unbudgeted data work (Accenture, FY25). Putting it on the map turns an expensive surprise into a budgeted stage.
Four areas of work
02
ARISE, our modernisation framework
Our own framework: four phases (Analyze, Migrate, Build, Deploy) and nine agents in an audited, reproducible pipeline, with a senior engineer validating before each stage change.
03
OWASP Top 10 security
Vulnerabilities classified by severity with a prioritised remediation plan. Mobile Top 10 and MASVS v2 when there is a field app.
04
SAP modernisation
Z transaction documentation with a dependency tree and business rules, S/4HANA readiness, and migration of critical ABAP logic when S/4HANA is not the destination.
Manuka case
eCommerce migrated from PHP and MariaDB to Blazor .NET 8: from 16 weeks to 2, zero build errors and 100 % of the data migrated.
SAP: document your Z portfolio before the migration is quoted
The end of standard maintenance for SAP ECC has a date and it is in your contract. What is not is how much the migration will cost if you quote it without knowing what is inside. Documenting the Z portfolio changes which side of the table holds the information.
With the portfolio documented
Without documentation
You know how many Z transactions you have, which ones are used and which can be retired before migrating.
The scope is defined by whoever is going to charge for the migration.
The dependency tree shows what breaks if you touch each object.
Surprises arrive at cutover, when there is no margin left.
Business rules are written down and stop living in one person's memory.
The day that person retires, the knowledge leaves with them.
You can assess whether S/4HANA is the destination or whether logic should move to another stack.
The only available option is the one the vendor proposes.
The three questions we always get
How do I know the migrated system does the same thing?
Every phase has a human validation gate. The behaviour of the legacy system is compared against the migrated one before moving to the next stage.
Does this consume my team's hours?
The work runs in parallel to your operation. Your team takes part in the target architecture design and in the final testing, not in the day to day of the migration.
Who maintains the code afterwards?
Your own team. We hand over documented code they understand. If they cannot maintain it, the project is not finished.
How it starts
With one bounded domain, not the whole company.
We pick the domain or the system that already has a question waiting for an answer. It is how the work pays for itself before it ends.
- Inventory and real state of that domain's sources
- Shared definitions and permissions, before connecting anything
- ARISE diagnostic of the system blocking it, with effort estimated per phase
- Fixed scope and price, no hourly billing
Frequently asked questions
- Which languages and stacks do you support?
- Source: COBOL, Visual Basic, ASP Classic, .NET Framework, legacy PHP, Java, Oracle Forms, ABAP and AS/400. Target: .NET 8+, Java, Node.js, Python, Angular, React, Blazor, SQL Server, PostgreSQL and S/4HANA.
- How does ARISE compare to tools like Panaya for SAP?
- Panaya and similar tools handle testing and impact within the same stack. ARISE modernises across stacks: it migrates logic, data and documentation, and leaves maintainable code. They are complementary: several S/4HANA projects use ARISE to document the Z portfolio.
- Does my code leave my infrastructure?
- Not without prior agreement. They run in a private Azure cloud or in your own tenant, with no public APIs, and we sign an NDA before receiving a line of code.
- What if my legacy system works fine?
- Then we leave it alone. We only modernise what blocks something concrete: an integration that cannot be built, a security risk, a dependency on one person, or a regulatory requirement with a date.
Let us start by knowing what systems you have and what risk they carry today.
The diagnostic delivers the technical risk map, the effort estimate per phase and the plan prioritised by business impact.