Agile System Software

Partner guide · Windows modernization

Old Windows apps, modernized stage by stage.

AI does the work. The client approves every stage. The old app proves the new one. This guide gives you what you need to find the right clients and start the conversation.

  • VB6
  • .NET Framework
  • Delphi
  • Access
Watch the explainerGo to the partner playbook
The client stays in controlThey approve before each stage and sign off after it.
Proof, not promisesThe old app and the new app are compared by the engine.
Cost in small, capped stepsA budget per stage. Go or no-go after the pilot.

The one-minute summary

If you read only one section, read this one.

What it is

Agile System Software moves a company's older Windows app to a modern platform, and proves that the new app behaves like the old one.

Who it is for

Companies that depend on an app built in VB6, .NET Framework, Delphi or Access, and cannot afford to get the change wrong.

How it works

A modernization is not one long build. It is a programme of stages. Every stage runs the same five steps: Fable 5.2 drafts the plan, the client approves it, AI agents build and test, the old app proves the new one, and the client signs off. Only then is the next stage planned.

Why it is different

The AI never approves anything. The client does, through named people. And nobody has to take the result on trust: the old app runs on our legacy Windows seat, the new app runs on the same inputs, and the engine compares the two.

Words we use

Client
The company that buys the modernization and owns the old app.
Stage
One step of the programme, with its own plan, budget and sign-off.
Stage spec
The plan for one stage: goal, scope, exit criteria and budget. The client reads a short summary.
Sign-off
The client's recorded acceptance of a finished stage.
Programme Profile
The client's priorities and choices, turned into settings for every stage.
Legacy Windows seat
Our isolated environment that runs the old app, so its behaviour can be captured.
Engine
Our AI modernization engine. It runs each stage's work with AI agents and does the comparing.

Who it's for

Typical situations you will meet. In each one, the business rules live inside the old app. The aim is to keep the behaviour and change the platform.

A VB6 desktop app nobody can maintain

It still runs orders, stock or billing every day. The people who wrote it have moved on, and every change feels risky.

An Access database that outgrew itself

It started as one person's tool. Now a whole team depends on it, with forms, reports and years of data inside.

An old .NET Framework app

A WinForms or WebForms app built years ago. It works, but it is hard to extend and hard to find people for.

A Delphi app

A solid desktop program that the business trusts. Few people are left who can safely change it.

What they have in common. The app still works, the business depends on it, and the client is afraid to touch it. They do not want one big rewrite that might fail. They want small steps, proof at each step, and a clear way to stop.

How a modernization runs

One simple cycle, repeated for every stage. Then the stages, in a fixed order, sized to the client.

Every stage: the same five steps

The five steps of every stageFable 5.2 drafts the stage spec. The client approves the spec and budget. AI agents build and test. The old app proves the new one. The client signs off. Then the next stage is planned.1AIFable 5.2 draftsthe stage spec2ClientThe client approvesspec and budget3AIAI agentsbuild and test4EngineThe old appproves the new one5ClientThe clientsigns offNot approved? Fable 5.2 redrafts.A criterion failed? Rework,inside the same budget.Then the next stage is planned1Fable 5.2 drafts the stage spec2The client approves spec and budget3AI agents build and test4The old app proves the new one5The client signs offThen the next stage is planned, and the cycle repeats.

We run our own quality check before each client step. That check only decides "ready to show the client". It is never an approval.

The stages, in order (the compact plan for Windows apps)

How a Windows modernization runs, stage by stageAssess, then Framework and Tooling, then the Pilot. After the Pilot the client decides: go, re-scope or stop. On go, Batches repeat until the whole app is done. Then Performance when needed, Acceptance, Parallel run when required, Cutover, and Hypercare and Close.1AssessMeasure the old app2Framework + ToolingDecide, lay the foundation3PilotProve it on a sliceThe clientdecidesgo4BatchesThe rest, in groupsnext batchRe-scope: a change request with a costed impact, approved by the client.Stop: the programme closes. The client keeps everything delivered.when thewhole appis done5PerformanceSpeed, resilience6AcceptanceUsers accept7Parallel runOld and new together8CutoverThe switch9Hypercare + CloseStabilise, retire the oldIn every programmeAdded when the client's targets or rules call for itEvery box runs the five-step cycle, with the client's approval and sign-off.1AssessMeasure the old app2Framework + ToolingDecide, lay the foundation3PilotProve it on a sliceThe client decidesGo, re-scope or stop4BatchesThe rest, in groups5Performance (when needed)Speed, resilience6AcceptanceUsers accept7Parallel run (when required)Old and new together8CutoverThe switch9Hypercare + CloseStabilise, retire the old

The compact plan is the default for Windows apps. It joins Framework with Tooling, and Hypercare with Close, so a small app has fewer steps. On request, the standard plan runs each of those as its own stage. No plan removes the client's approval or sign-off.

Each stage at a glance

For every stage: the goal, what the client decides, what the client gets, and who on the client side approves and signs.

1

Assess

Know exactly what the old app is before anything is decided.

The client decides

  • Is the scope right?
  • Is the plan for each part right: convert, rewrite, retire, retain or replace?
  • Is the data policy acceptable?

The client gets

  • An inventory of the whole app: its screens, code, reports and data, and how they depend on each other
  • A list of the Windows parts the app relies on
  • The risks, named early
  • A proposed list of stages
  • A price range

Approves the spec and budget: Sponsor, IT architect
Signs off the result: Sponsor, IT architect; Risk for the data policy

2

Framework and Tooling

Joined stage

Fix the client's decisions. Then build and prove the foundation the new app will run on, and the tools every later stage reuses.

The client decides

  • Their answers to the decision questionnaire (the Programme Profile)
  • Does the architecture match what they chose?
  • Can their staff read the sample code?
  • Is the sign-in and role mapping acceptable?
  • Is the test strategy acceptable?
  • Which test data may be used: synthetic, masked or real?

The client gets

  • The signed Programme Profile
  • Architecture and design documents
  • The tested foundation for the new app
  • A first simple screen taken end to end and compared with the old app
  • Converters, each certified by the engine
  • The tooling that captures and compares old and new
  • Data loaders and test environment definitions

Approves the spec and budget: Sponsor, IT architect, Risk
Signs off the result: IT architect, Risk, Operations; Business expert for the test strategy

3

Pilot

Prove the whole method on a small, representative slice before the client commits to the rest. Measure the real cost.

The client decides

  • Which slice to use
  • Are the extracted business rules right?
  • Any difference between old and new: accept it or not?
  • The result of a short user test
  • Go, re-scope or stop, against criteria written before the run

The client gets

  • The business rules of the slice, written down and traced to the old code
  • The converted slice, tested
  • A report that old and new match
  • The first measured costs, used to quote what follows

Approves the spec and budget: Sponsor, Business expert, IT architect
Signs off the result: Sponsor (go / no-go), Business expert, IT architect; Risk for regulated clients

4

Batches

Repeats

Take the next group of screens, code and reports through the same cycle. Repeat until the whole app is done.

The client decides

  • Are this batch's business rules right?
  • Any difference between old and new: accept it or not?
  • Spot checks on the live watch page

The client gets

  • The batch's rules, code, tests and match report
  • A re-check of every earlier batch
  • Updated costs and a forecast for the batches that remain

Approves the spec and budget: Sponsor, Business expert, IT architect
Signs off the result: Business expert, IT architect; Risk for differences on money fields

5

Performance

When needed

Show that the new app meets the client's own speed and resilience targets.

The client decides

  • Where a target is missed by a margin: is the measured value acceptable?

The client gets

  • Measured results for response time, scheduled jobs, load, stress and recovery
  • Each result set against the client's target

Approves the spec and budget: Sponsor, IT architect, Operations
Signs off the result: Operations, IT architect

6

Acceptance

The whole app, accepted by the people who will use it and run it.

The client decides

  • User acceptance testing, run by the client's users
  • Operational acceptance, by operations
  • Regulatory acceptance, by risk and compliance, where it applies

The client gets

  • A full re-check of every captured run
  • End-to-end and security tests
  • Final documents and the release
  • The evidence pack

Approves the spec and budget: Sponsor, Business expert, Operations
Signs off the result: Sponsor, Business expert, Operations, Risk

7

Parallel run

When required

Run old and new on the same real inputs, cycle after cycle, and rehearse the move.

The client decides

  • How many cycles, and the rule for passing (set in the spec)
  • Any difference found with real data: accept it or not?

The client gets

  • A comparison for every cycle
  • Data migration rehearsals
  • A tested rollback

Approves the spec and budget: Sponsor, Operations, Risk
Signs off the result: Operations, Business expert, Risk

8

Cutover

Switch to the new app. The client carries it out. Our engine never touches the client's production.

The client decides

  • Go or no-go
  • Roll back or stay

The client gets

  • The final runbook and a final rehearsal
  • A go / no-go pack
  • A final reconciliation of the data
  • A rollback watch for the agreed window

Approves the spec and budget: Sponsor, Operations, Risk
Signs off the result: Sponsor, Operations

9

Hypercare and Close

Joined stage

Stabilise the new app and hand it over to the client's team. Then retire the old app and end the programme.

The client decides

  • Are the exit criteria met? For example, a clean first period end.
  • Switch-off of the old app
  • What is kept, and for how long
  • Deletion of our copies of the client's data

The client gets

  • Bounded defect fixing
  • Training and knowledge transfer
  • A switch-off checklist and the archive
  • The final evidence pack
  • Deletion of client data

Approves the spec and budget: Sponsor, Operations, Risk
Signs off the result: Sponsor, Operations, Risk

How we prove the new app behaves like the old one

The old app is the specification. We do not ask anyone to take the result on trust.

The old app proves the new one

How the old app proves the new oneThe old app runs on our legacy Windows seat and its screens, outputs and data are captured. The new app runs on the same inputs and is captured the same way. The engine compares the two, field by field. The result is a match, or a difference that the client decides on.The old appruns on our legacy Windows seatThe new appruns on the same inputsCapturedscreens, outputs and dataCapturedthe same wayThe engine comparesfield by fieldMatchthe stage can passA differencethe client decides1The old app runson our legacy Windows seat2The run is capturedscreens, outputs and data3The new app runson the same inputs4The engine comparesold and new, field by field5Match, or a differencethe client decides on each difference

The engine's comparison gives the verdict. No AI model writes it.

How it works, step by step

  1. The old app runs on our legacy Windows seat. The client supplies the source code, the compiled program and sample data.
  2. Its behaviour is captured. For each recorded case we keep the inputs, the screens, the outputs and the data before and after.
  3. The new app gets the same inputs. It is captured the same way.
  4. The engine compares the two, field by field.
  5. A stage passes only when nothing is different and nothing is missing, apart from differences the client has approved.
  6. Every later batch re-runs the captured cases of the batches before it, so new work cannot quietly break old work.

What the client decides

  • What "the same" means: no differences at all except named ones, or stated tolerances.
  • Whether a known bug in the old app is kept or fixed. A fixed bug is a changed rule. It is not presented as proven equal.
  • Each difference the comparison finds: accept it, or have it fixed. A difference counts as accepted only after the client approves it.
  • Whether screens stay like the old ones or are redesigned.

The client can watch

A live watch page shows the old app and the new app side by side, with the verdicts. The client's own experts can spot a problem early.

Be honest about limits. Screens that are kept like the old ones can be compared field by field. Screens that are redesigned cannot, so they are accepted through the client's user testing instead. If part of an old app cannot be run on our seat, the stage spec says so before the client approves it, and the evidence labels it. Converting a Windows app does not get everything right in one pass. That is why the Pilot measures the result on the client's own code before they commit to the rest.

Roles on the client side

Approvals come from named people in five roles. Help your prospect find these people early.

Sponsor

Business owner or budget holder

Every stage budget. Go or no-go. Stop. The list of stages.

Business expert

Senior user or analyst

The business rules. Differences on business fields. User acceptance testing.

IT architect

Lead developer or head of IT

Technical choices. The foundation and converters. Whether the code is readable.

Operations

Whoever runs the app day to day

Performance, operational acceptance, cutover and hypercare.

Risk and compliance

Risk officer, security officer

The data policy. The sign-in and role mapping. Differences on money fields. The evidence packs.

Good to know

How the roles work

In a small company, one person may hold several roles, unless a regulatory regime the client names asks for separation. The client sets how many people sign in each role.

StageApproves the spec and budgetSigns off the result
1. AssessSponsor, IT architectSponsor, IT architect; Risk for the data policy
2. Framework and ToolingSponsor, IT architect, RiskIT architect, Risk, Operations; Business expert for the test strategy
3. PilotSponsor, Business expert, IT architectSponsor (go / no-go), Business expert, IT architect; Risk for regulated clients
4. BatchesSponsor, Business expert, IT architectBusiness expert, IT architect; Risk for differences on money fields
5. PerformanceSponsor, IT architect, OperationsOperations, IT architect
6. AcceptanceSponsor, Business expert, OperationsSponsor, Business expert, Operations, Risk
7. Parallel runSponsor, Operations, RiskOperations, Business expert, Risk
8. CutoverSponsor, Operations, RiskSponsor, Operations
9. Hypercare and CloseSponsor, Operations, RiskSponsor, Operations, Risk

Why clients trust it

Eight principles you can say out loud in a meeting.

The client decides at every stage

A stage starts only when the client approves its spec and budget. It ends only when the client signs off.

Approval is a real, recorded act

Named people approve, signed in, each in their role. An AI model can never approve. We alone can never approve. Silence is never approval.

The old app is the specification

The engine runs the old app, captures what it does and compares that with the new app. The engine's comparison gives the verdict. No AI model writes it.

Evidence, not claims

Each approval and sign-off is recorded with the person, role and time, tied to exactly what was signed, and linked to the record before it. The result is evidence an auditor can review later.

Small, proven steps

No stage commits the client to the next one. The client may stop at any stage boundary and keep everything delivered.

Always a tested way back

Nothing irreversible happens without a tested rollback. The old app stays runnable until the client signs the final stage.

The client can watch

A live watch page shows old and new side by side, with the verdicts. The client's own experts can catch a problem early.

Honest limits, written down

Anything that could not be run or tested, and anything an AI model judged, is labelled in the evidence.

How risk and cost stay controlled

The client never signs a blank cheque. They approve a budget for one stage at a time.

One stage, one budget

Each stage runs as one job with its own budget ceiling. The client approves that ceiling with the spec.

The job stops at the ceiling

A budget guard warns early, with a forecast, and stops the job at the ceiling. No stage runs uncapped.

No increase without the client

A budget can be raised only through a change request the client approves.

Measured, then quoted

Assess gives a price range. After the Pilot, each next budget is worked out from measured costs. The margin for the unknown shrinks as forecast and actual come together.

Forecast against actual, every time

At every sign-off the client sees what was forecast and what was spent. It is part of the evidence.

Go, re-scope or stop after the Pilot

The sponsor decides against criteria written before the Pilot ran. Stop is always allowed, and the client keeps every signed deliverable.

Changes are costed first

For any change, Fable 5.2 drafts the impact: what must be redone and what it adds to the budget. Only the work that depends on the change is redone. The client approves before anything runs.

Waiting costs nothing

While the programme waits for the client, nothing runs and nothing is spent.

Technologies and scope

Agile System Software modernizes older Windows systems. What we can prove depends on what our legacy Windows seat can run today. Here is the honest picture.

TechnologyComparison todayWhat the seat doesLimits to tell the client
VB6AvailableThe seat runs compiled VB6 programs, with the standard VB6 runtime, the common VB6 controls and the Jet, DAO and ADO data layer.The client supplies the compiled program as well as the source code. Large real-world apps have not been proven on the seat yet, so the Assess and Pilot stages measure this on the client's own app. Printing and sound are untested. For other third-party controls or COM components, check with us first.
.NET FrameworkAvailableThe seat builds and runs C# and VB.NET projects for .NET Framework 2.0 to 4.8, including WinForms windows.Large WinForms apps and some VB.NET features are untested. Running ASP.NET WebForms pages on the seat has not been proven yet, so check with us first for a WebForms app.
DelphiAvailableThe seat runs compiled 32-bit Delphi programs. Code that does not depend on Delphi's visual component library can also be compiled and checked on the seat.The client supplies the compiled program as well as the source code. Large real-world apps have not been proven on the seat yet; the Assess and Pilot stages measure this.
AccessData: availableThe seat reads Access database files (.mdb and .accdb) directly: tables and data. The Jet data layer that Access apps use also runs.Running Access forms, reports and macros on the seat has not been proven yet. Check with us first. The data can still be captured and compared.
Classic ASPNot available yetThe seat cannot run classic ASP sites for comparison yet.A project with classic ASP is not accepted until support is ready. Check with us first.
PowerBuilderNot available yetThe seat cannot run PowerBuilder apps for comparison yet.A project with PowerBuilder is not accepted until support is ready. Check with us first.

The target

The client chooses the target in the questionnaire, from the targets we support at the time. The video shows a web app as the example. Ask us for the current list before you discuss a specific platform.

The plan

The compact plan by default; the standard plan on request. A Parallel run is usually optional for a Windows app. It is required when the client names a regulatory regime or the app handles money. A Performance stage is required when the client sets speed targets or names a regime. The rollback test always stays.

The evidence

A lighter evidence pack than a regulated programme needs, with the same chain of approvals and sign-offs. All material is in English.

Decisions that are specific to Windows apps

The questionnaire in stage 2 covers the choices that most often change behaviour when an old Windows app moves:

  • How numbers round, and how money amounts are stored
  • How empty values, dates and regional settings behave
  • Which database types the data moves to
  • Screens: kept like the old ones, or redesigned for the web
  • COM components and 32-bit-only parts the app depends on
  • Sign-in: Windows or directory accounts, mapped to roles in the new app
  • Reports: which must match the old ones exactly

When in doubt, check with us first. The seat has been proven with test programs for each technology marked available. It has not yet been proven on large real-world apps. So we do not promise in advance that a given app will run on it. The Assess stage finds out, and the stage spec states what cannot be run before the client approves anything.

Common client questions

Short answers you can give. If a question goes beyond these, bring us in.

Does the AI make the decisions?

No. Fable 5.2 drafts each plan and reviews the work. AI agents build and test. The client approves every stage and signs it off. Whether old and new match is decided by the engine's comparison, not by an AI model.

How do we know the new app behaves like the old one?

The old app runs on our legacy Windows seat, and its screens, outputs and data are captured. The new app runs on the same inputs, and the engine compares the two, field by field. A stage passes only when nothing is different and nothing is missing, apart from differences the client has approved.

What if we want something to work differently, or the old app has a known bug?

The client decides what "the same" means: keep a known bug or fix it. Each intended difference is listed and approved by the client. It is then a changed rule, and it is not presented as proven equal.

What do you need from us to start?

The source code, the compiled program that runs today, and sample data. The client also names the people who will approve and sign. In the Assess stage they sign a data policy before any AI model works on their material.

What will it cost?

There is no single up-front figure. The Assess stage gives a price range. Every stage then has its own budget, approved by the client before it starts. A job stops at that ceiling, and only a change request the client approves can raise it. After the Pilot, budgets come from measured costs. The client also chooses the commercial model in the questionnaire: a fixed price per stage, or capped time and materials.

Can the client stop part-way?

Yes, at any stage boundary. They keep every deliverable they signed off.

How long does it take?

It depends on the size of the app and on how fast the client can review and approve. The Assess stage produces the proposed list of stages. Please do not promise dates before that.

How much of the client's time does it need?

Named approvers review a short summary before each stage and the report after it. The business expert confirms the extracted rules. The client's users run acceptance testing. Each stage spec lists the client's duties, with dates. In a small company one person may hold several roles.

Do you need access to our live system?

No. The client supplies the source code, the compiled program and sample data. The client carries out the cutover. Our engine never touches the client's production.

What about our data and AI?

The client signs a data policy in the Assess stage. They choose whether tests use synthetic, masked or real data. They also state where source code and data may be processed. The first scan of the app is done by the engine alone. AI models start work only after the data policy is signed. If a prospect has strict rules on this, raise it with us early.

The old app keeps changing during the project. Is that a problem?

No. Each new drop of the old source is scanned again. The changes are listed, and Fable 5.2 drafts a change request with its cost for the client to approve.

What does the new app run on?

The client chooses the target in the questionnaire, from the targets we support at the time. The video shows a web app as the example. Ask us for the current list before you discuss a specific platform.

Our app uses classic ASP or PowerBuilder. Can you take it?

Not yet. We cannot run those for comparison today, so we do not accept such a project until support is ready. Check with us first. We would rather say so than promise a proof we cannot give.

The partner playbook

How to open the conversation, what to ask, how to tell a good fit, and the two ways to sell.

The short pitch

"You depend on a Windows app that is hard to change and risky to replace. We modernize it in small stages. AI does the heavy work, but your people approve every stage and its budget. Your old app proves the new one: the two are run on the same inputs and compared. After a pilot you decide: go, re-scope or stop. You can stop at any stage and keep what was delivered."

Discovery questions to ask a prospect

  1. What is the app written in: VB6, .NET Framework (WinForms or WebForms), Delphi, Access? Is any part classic ASP or PowerBuilder?
  2. What does the app do for the business? Does it handle money?
  3. Roughly how big is it: screens, reports, database tables, links to other systems?
  4. Is the source code available? Is there a compiled program that still runs today?
  5. Where is the data kept? An Access file, or another database?
  6. Does it depend on third-party controls, COM components or 32-bit-only parts?
  7. How do users sign in today?
  8. Why modernize now? Skills, risk, cost, a platform that is hard to keep running?
  9. What matters most: the same behaviour, code their team can maintain, speed of delivery, cost, security?
  10. Who would be the sponsor? Who knows the business rules? Who looks after IT and day-to-day running?
  11. Are there rules on where source code and data may be processed, or on test data?
  12. Has a rewrite been tried before? What went wrong?

Signs of a good fit

  • A business-critical Windows app that the client is afraid to touch
  • Built in VB6, .NET Framework, Delphi or Access
  • The source code is available, and the compiled program still runs
  • A named sponsor with a budget
  • Someone who knows the business rules, and users who can test
  • The client wants control, proof and a clear way to stop

Signs to slow down

  • They want a fixed total price and date before any assessment
  • Nobody on the client side can approve or sign
  • The source code is lost, or no working copy of the program exists
  • The app is mostly classic ASP or PowerBuilder (not available yet)
  • They want to buy a packaged product instead of keeping their own logic
  • The system is not an older Windows system. That is outside this offer.

Please do not promise

  • A total price or an end date before the Assess stage
  • "Fully automatic" or "no client effort"
  • A certification or a compliance guarantee
  • A specific target platform before you have checked the current list with us
  • That every screen can be compared automatically. Some parts are accepted through user testing, and the stage spec says which.
  • Skipping a stage, an approval or a sign-off

Your next steps with a prospect

  1. OpenUse the short pitch. Show the video below.
  2. QualifyAsk the discovery questions. Note the technology, the rough size and who would sponsor it.
  3. IntroduceBring us in with your notes. If the app uses anything marked "check with us first", say so.
  4. Propose AssessThe first stage is small and useful on its own: the client gets an inventory, the risks, a stage list and a price range.

Two ways to sell

Model 1

Resell our stages

You find the client and stay close to them. We deliver each stage.

  • You open the door, qualify the prospect and introduce us.
  • We run the stages: the specs, the build, the comparison and the evidence.
  • The client's named people approve and sign off every stage, as described in this guide.
  • A good fit if you sell and advise, and do not want to run delivery yourself.

Model 2

Deliver it yourself, powered by our engine

You sign the client and deliver the modernization as your own service. Our engine does the stage work for you.

  • You run the programme and own the client relationship.
  • Our engine drafts the specs, builds, tests, runs the old app on our legacy Windows seat and compares.
  • The same rules hold: the client approves and signs off every stage, and no stage is skipped.
  • The evidence pack carries a "powered by" line that names our engine.
  • A good fit if you have your own delivery team and want to offer this under your name.

Ask us for the current commercial terms of each model. This guide does not quote prices.

Watch: how Windows modernization works

A drawn explainer, 2 min 21 s long, with captions. It follows a fictional distributor's VB6 order-entry app, with an Access database, through the stages. Share it with prospects.

Title frame of the explainer video: Windows modernization, stage by stage

The client in the video is an invented example. No real company is shown.

Agile System Software · Windows modernization · Partner guide · agilesystemsoftware.com

For partners of Agile System Software. This guide describes the method at a high level. The stage spec agreed with each client is what governs a real project.

For partners and resellers: list prices, discounts and the partner programme. Partner pricing →