Legacy modernisation for business software that still works
“This is what we use today. We want to do the same things — much more simply.”
Keep the system that runs your business. We build a simpler way for your staff to use it. The old program keeps doing the work behind the scenes — your data, your rules and your existing connections to suppliers, stock and accounting stay exactly where they are. Your staff just stop memorising codes.
TODAY — KUNDREGISTER V4.2
4 SCREENSF2=SÖK F4=FORDON F7=ORDER ESC=MENY ──────────────────────────────────── KUNDKOD....: KU-10428_ NAMN.......: NORDVIK TRANSPORT AB ORT........: UPPSALA RAB.KOD....: 12 BET.VILL: 30D SALDO......: 14 320,00 KREDIT: OK ──────────────────────────────────── > F4 för fordon > F7 för ny arbetsorder ERR 0x27: OGILTIGT FÄLTVÄRDE
THE CUSTOMER NUMBER MUST BE KNOWN BY HEART. VEHICLES, ORDERS AND HISTORY EACH LIVE ON THEIR OWN SCREEN.
After — one customer view
1 SCREENNordvik Transport AB
Uppsala · 2 vehicles · 12% discount · 30 days
KRT 421
Volvo FH16 · 2019
Service due in 3 200 km
MHB 730
Mercedes Sprinter · 2021
Last visit 12 March
Latest order
#10492 · delivered
Contact
Anna Lind · 018-12 34 56
Search by name, registration number or phone. The original program still calculates the price and creates the order number.
- 2
- interfaces to one system: the old one and the new one
- 1
- source of truth — still the original program
- 0
- data migration needed to get started
The problem
The old program still works. That is exactly why it is hard to leave.
Knowledge sits with one person
An experienced employee knows every code by heart. A new hire needs weeks of training before they can take an order.
Simple tasks take many steps
Find a customer, check a product, place an order — three screens, three code lookups, the same details typed twice.
Switching feels risky
The data has to stay right, staff must keep working, and anything new has to handle the company's own routines — which is why replacing the program is the wrong place to start.
In the old program
Through the new interface
Commands and function keys you must memorise
Clear buttons and menus
Customer data spread over several screens
One combined customer view
The same detail typed in again and again
Details reused automatically
Search only works with exact codes
Search by name, number or article
Cryptic error messages
Plain explanations and help to fix it
The point is to simplify the whole workflow — not to change the colours and swap text for buttons.
How the two interfaces fit together
Two ways into the same business system — the old one, and a simple new one
Instead of the customer menu, a customer number, a function key for orders and an article code, your staff search for the customer, pick the product, type a quantity and press “Create order”. Behind the scenes it is translated into whatever the original program needs, and the order number comes back from the original program itself.
01
The new interface
Shows the information, takes the choices, removes the steps nobody needs to see. One customer page instead of four screens.
02
The connection module
The translator between the new interface and the old program's way of taking commands and returning answers. This is the real engineering work.
03
The original program
Performs the actions, applies its rules, keeps its existing links to stock, suppliers and accounting. Still the source of truth.
Clear from the start
Your system is never replaced
Nothing is converted, migrated or re-learned from scratch. The old program stays where it is and keeps making the calculations, applying its rules and running its external connections — the new interface is only an easier way to use it.
Make the choices a member of staff would make
Customer
Nordvik Transport AB
Part
Bromsklossar fram
Qty
4
Press the button and watch what the old program is made to do.
The original DOS program — running underneath
ONE CLICK → STEPS IN THE ORIGINAL PROGRAMIDLE
C:\KUNDREG>█
With an API, we use it
The module sends the customer number, article number and quantity to the existing functions. But the API has to support the task — one that can only read customer details cannot create orders.
Without an API, we drive the program
The module works like a very fast employee: reads which screen the program is on, fills the right fields, sends the keystrokes, waits, then reads the confirmation or the error. A terminal session gives clean screen text; a local DOS program may need a compatible environment.
Questions are passed to the person
When the old program asks whether to back-order an item, the new interface shows that question and waits for a real answer. It never continues on a guessed choice.
Several users at once
Two people cannot type into the same session independently. Depending on what your program supports we run separate sessions or a controlled queue — keeping each user's own permissions and a record of who did what. The new interface does not raise the original program's user limit.
“Sent” is not the same as “done”
If the connection drops after Create order, the order may already exist. The module checks the result — a confirmation, or by looking the order up again — and if it is unclear it says so instead of falsely reporting success.
Nothing happens unseen
Every command sent to the old program is recorded: which screen, which keys, which answer came back. If a result is ever questioned, the whole sequence can be read line by line.
Where it runs
If the program only exists on your internal network, the connection module is installed there and the new interface talks to it over an approved, protected connection — or the whole solution stays inside your network. A website does not get access to your servers by itself; the access and permissions are set up deliberately.
Start with the everyday tasks
The first version does not need every function. Customer search and order entry cover most of the day; rare tasks like year-end routines stay in the original program. Each workflow is checked so the same input gives the same result through both interfaces.
How the service works
Five stages, each with something you can check
Access & walkthrough
You give us a copy of the program and its data in a test environment, plus source code, documentation or an API if it exists. Then you show us a few everyday tasks.
Mapping
We document three things: the data and how it connects, what users can actually do, and the rules — pricing, required fields, and what happens when something changes or fails.
Proposal & prototype
You get a scoped proposal and a working prototype with test data. You run your real workflows and give feedback before anything goes live.
Verification
We run the same order through both interfaces and compare totals, discounts and stock movements — including returns, cancellations and missing data.
Start using it
The workflows you use every day go live first, in stages if that is safer. Nothing is switched off — the old program stays, and we stay on for operations, backup and support.
Not only DOS
If your staff work in a green terminal window, we can simplify it
The same approach works whenever people type commands and codes into an older system all day long. The system underneath keeps running exactly as it does today.
DOS-era business software
Order entry, stock, invoicing and parts written in the 80s and 90s — still the heart of the company.
Terminals and mainframes
AS/400, IBM i, Telnet and SSH sessions where every task is a command and a function key.
Telecom & Wi-Fi support
Line tests, router and modem diagnostics, port status and network databases that agents read as raw text and cryptic codes.
Older Windows programs
Delphi, Visual Basic, Access and early versions of standard business systems.
Support desk today
Four windows to answer “is my router online?”
The agent switches between separate tools and terminal sessions, types the customer ID and the line identifier by hand, runs the test command and reads forty lines of raw output to find the one that matters. The customer waits on the line, and a new agent needs weeks before doing this alone.
Through the new interface
One search, plain status, one click
Search by phone number or customer number and see it in plain words: router online or offline, signal, connected devices, latest alarm. Buttons for the everyday actions — run a line test, restart the connection. The existing systems run the same commands as always, with the agent's own permissions and a record of who did what.
Typical case · illustrative example
A parts distributor taking an order — before and after
This is a typical example, not a named customer. It shows the same everyday task done the old way and through the new interface, with the original program still doing the work. See the full before & after walkthrough →
Before — in the DOS program
Four screens, twenty-two keystrokes
- Workflow. F7 → customer number → TAB ×3 → article code → price list. Four different screens for one ordinary parts order.
- Training. Six to twelve weeks before a new hire can take an order without asking for help.
- Key-person risk. Two people in the company know every shortcut and error code by heart.
- Time per order. About three minutes, often with handwritten notes in between.
After — through the new interface
One screen, one search field
- Workflow. Type the customer name or registration number, pick the parts, press “Create order”.
- Training. Ten minutes. Anyone can take an order on day one, including staff out in the workshop on a tablet.
- Same engine. The original program still calculates, reserves stock and sends data on to the wholesaler in the background.
- Time per order. Around twenty-five seconds.
~80%
less handling time per order
2 months → 15 min
to train someone to take an order
0 hours
downtime while it is put in place
Trust & security
Three ironclad guarantees for the person who signs
You are not asked to gamble with the system that runs your company. Every step is reversible, and nothing is switched on before you have seen it work.
Zero downtime, safe test copy
We never touch your live server while building. You copy the program folder onto a USB stick, we work against that isolated test machine. If something breaks there, your business loses exactly zero seconds.
Your data never leaves the building
The connection module and the new interface can run entirely on your own internal network. Customer records, price lists and margins never have to be sent anywhere outside your walls.
Full right to change your mind
Not one line of the original program is rewritten. If the staff prefer the keyboard on a Friday afternoon, they turn around and press F7 exactly like yesterday. There is no point of no return.
The painless four-step pilot
NDA and a test copy
A short confidentiality agreement, then 15 minutes of copying. You own all your data.
Sandbox demo
Within days you see your own customers, your own articles and your own logo in a clickable interface.
Shadow running
The same orders are placed both ways for a week. Totals, VAT, discounts and stock must match to the öre.
Soft rollout
One workflow at a time — search first, then orders. Rare tasks stay in the old program.
What the alternatives cost you
A company with a DOS or terminal system has three painful options today
01
A modern off-the-shelf system
500 000 – 2 000 000+ kr
Monitor, SAP, Business Central. 6–18 months, every external connection rebuilt from scratch, and a huge risk of stopping the business.
02
A traditional IT consultancy
1 000 000 – 2 500 000 kr
Three developers for 4–6 months. Budgets drift, delivery is uncertain, and you pay for the hours either way.
03
Doing nothing
The quiet, ongoing cost
New staff cannot be trained, slow processes lose customers, and the only person who knows the key commands is close to retiring.
The fourth option
Keep the engine that already works. Get a modern way to use it in weeks — not a million-krona rebuild.
No data conversion, no lost integrations, no shutdown risk. You are priced on the value of the result, not on the number of hours it took.
How you buy it
A free look first, a small paid step second, the big decision last
Nobody is asked to buy a black box. Each step is smaller than the one before it, and each one ends with something you can look at, test and say no to.
01
A free demo by email
You write a few lines about what your program does. We send back a short demo of your own workflow in a modern interface — no meeting, no files, no obligation. In the same reply we tell you honestly whether your program is a good fit.
02
A paid mapping
You copy the program folder onto a test machine. We map the data, the functions and the rules nobody wrote down — and build a working interface on your own test data, so you see your own company on screen rather than a mock-up.
03
The build
You approve the prototype, then we build the full connection module and the interface around the workflows you use every day. Half when we start, half when you have tested it and said yes.
04
Shadow week, then everyday use
The same orders are placed both ways for a week — totals, discounts and stock must match. Then the everyday flows start, and operations, backup and support run monthly.
Payment terms
Half when we start, half when you have tested it and approved it.
Nothing large is paid before you have seen the result. The mapping fee is the only money that moves before a prototype exists — and the documentation from it is yours either way, including if you decide to stop right there.
Commercial model
Three parts, priced per system — not per feature list
Paid mapping
Fixed fee · before any build
An assessment of your program, a working prototype on your own test data, a clear scope for what will be built, and a concrete quote. You own the documentation either way.
The bridge & interface
50% at start · 50% on approval
The connection module, the new interface and the verification, split into stages you can approve one by one. The final half is due only after you have tested it in your own environment.
Operations
Monthly
Hosting, backup, support and agreed maintenance once you are live — so the connection keeps working after go-live, not just on the day we delivered it.
One flat price for every DOS program would not be honest: a simple customer register and a full ERP with stock, invoicing and special equipment are very different jobs.
Keep the system that runs your business. We build a simpler way to use it.
Start with a demo, not a meeting. Write a few lines about what your old program does and how your staff work today. We send back a short demo of the same workflow in a modern interface, so you can watch it whenever it suits you — no call, nothing to install, nothing in your calendar.
- —No data or program files are needed for the demo
- —If your system is not a good fit, we say so in that first reply
- —You also get a straight answer on what it would cost
- —The fixed-price mapping includes documentation that remains yours
- —Every workflow is verified against the original program before it goes live
Would rather send it yourself? support@framvy.com
Common questions
The questions we get most often
Do we have to replace our old business system?
No. The original program keeps running and stays the source of truth. The new interface is an easier way to use it — nothing is converted, migrated or switched off, and staff can go back to the old screen at any time.
How does the new interface reach an old DOS or terminal program?
A small connection module runs next to your program, inside your own network. Where an API exists, we use it. Where there is none, the module works like a very fast employee: it fills the fields, sends the exact keystrokes and reads the program's own confirmation back.
Does our business have to stop while it is installed?
No. The old program is untouched during the whole project. You test on a copy first, then run the same orders both ways for a week before anything becomes the everyday routine.
Can staff run it as a normal Windows program instead of in a browser?
Yes. It can be delivered as a web interface for laptops and tablets, or installed as a normal desktop program with its own icon and window — same solution, your choice.
Where does our data end up?
Your program and your database stay on your own machines. The connection module runs locally and talks to the interface over a protected connection; no business data has to be moved out of the company.
Which systems does this work with?
DOS-era business software, AS/400 and IBM i green screens, Telnet and SSH terminals, telecom and Wi-Fi support tools, and older Windows programs written in Delphi, Visual Basic or Access.
What does it cost and how long does it take?
A paid mapping with a working prototype comes first, then the build split half at start and half after you have tested it, then a monthly fee for operations and support. The first workflows are usually live in weeks, not months.