The screen that still closes the night
Somewhere in the building there is a desktop application that nobody wants to defend in a meeting and nobody will switch off. It might be a WinForms tool, a VB6 box, an Access file, or a FoxPro remnant with a dongle. The day staff talk about browsers and phones. The night shift still posts the job on that screen because it is fast, it is theirs, and the last time someone “upgraded” it, a Saturday order sat in a queue until Monday.
The useful decision is not “cloud or not”. It is wrap it, replace a slice, or leave it. A rewrite that starts from a blank ASP.NET solution is sometimes right. It is more often how you spend a year building a nicer screen for a job the night supervisor will not touch. This post is about choosing the cheaper honesty before anyone quotes a migration.
The work sits under legacy and cloud modernisation when you must move. It sits under .NET development when you build the next slice. It sits under MVP development when you need a test the night shift can fail in two weeks instead of in month nine. The words are different. The question is the same: will someone complete the job without you in the room?
Leave it — a decision you are allowed to write down
Leave it if the application still does the job, the person who runs it is not the only copy of the process, you can restore a backup, and nobody else needs the data except as a file you already export. Leave it if the machine is horrible and the risk is understood: a spare PC, a copy of the installer, a written note for the deputy. Leave it if a rewrite would be a prestige project for people who do not work at 2 a.m.
Leaving it is not neglect when you have written the conditions. Review them in June and again after the festival season. The moment you cannot restore, or the only operator books a long leave, or a customer needs a portal onto data that only lives in that box, you have left “leave it” and entered wrap or replace. Write the trigger in a sentence so a salesperson cannot reopen the year with a cloud slide.
Do not leave it and also promise a mobile app that reads the same data. That is a wrap you have not funded. Do not leave it and turn off the only person who understands the file layout. Handover is part of leaving. Source if you have it, a backup you have restored, and a page that says what the system does. If you cannot produce those, you are not leaving it. You are waiting for an outage.
Wrap it — an API sidecar, not a second office
A wrap means the desktop application stays the place the night shift works, and something else talks to the same truth. That something is usually a small API: read orders, post a status, export for Tally, show a read-only view on a phone for the supervisor who is not at the desk. The sidecar is not a second system of record. If staff start typing the same job in two places, you have failed the wrap.
Wraps work when you can reach the data safely — a database you understand, a file you can lock, a COM or HTTP surface the old vendor left behind. They fail when the only interface is the screen, and the only integration plan is “we will scrape it”. Scraping a desktop at 2 a.m. is how you create a third truth and a night-shift rebellion. If you cannot add a button or a query without a vendor, you are in modernisation first, not a chatbot on top of 2009.
A good wrap is boring. Authentication, an audit of who read or wrote, a limit on what the API can change, and a clear list of what still happens only on the old screen. The night shift should not need to know the sidecar exists. The accounts export should not need a retype. If the wrap requires a new login for the same job, you are already replacing a slice and calling it a wrap to make it sound cheaper.
Cost follows the access. If the database is ordinary and the schema is documented, a sidecar can be weeks. If the data is a proprietary file with a dongle and no backup, the first sprint is access and restore, not JSON. Be honest in the brief. Bolting a web login onto a system you cannot query produces a screenshot for the board and a process that still lives on the desktop.
Replace a slice — one job, one assumption
Replacing a slice means you pick one job the old screen does badly for someone who is not the night operator — dealer claims, a dispatch note the warehouse will record, a status the customer can see — and you build only that. The desktop remains for the rest. The new slice has to earn the next one. That is an MVP: narrow, real, hosted, with permissions and a way to undo. It is not a slide deck, and it is not a private demo with dummy data.
Write the expensive assumption as a sentence. “Warehouse staff will record dispatches here instead of WhatsApp.” “Dealers will raise a claim here instead of email.” Then build only what that sentence requires. Reports can wait. The bilingual help site can wait. The second warehouse can wait. If a director adds an item, something leaves the list or the date moves. An MVP with a growing first list is a rewrite in denial.
The night shift is allowed to refuse the new screen. That is data. If they still close the job on the old desktop after two weeks, you have learned something cheap: the slice was the wrong job, the incentive was wrong, or the new screen is slower at 2 a.m. than the muscle memory you mocked in the workshop. Do not “add features” to rescue a failed assumption. That is how a nine-month rewrite starts.
What we will not strip out of the slice: login, roles, backups, undo, a handover. Cutting those to hit a date produces a prototype. Call it that and budget the next step. Do not call it an MVP and then wonder why nobody uses it. The longer version of that argument lives on the MVP page. This post is about when that shape beats a wrap and when it does not.
Why the night shift refuses a new screen
They refuse because the old screen is faster in their hands than your demo was in a conference room. They refuse because the last new screen lost a Saturday. They refuse because they are measured on throughput, not on whether the company has a modern stack. They refuse because the mouse path is longer, the printer mapping broke, or the font is too small in a dim hall. None of that is stubbornness. It is the job.
If you need them to move, sit the shift. Photograph the sequence. Count the keystrokes. The new slice has to win on the same clock, or it has to be a different job — one they do not own. A customer portal does not need the night operator. A claims form for a dealer does not need the night operator. A “better” version of the same posting screen does. Design for the person who can say no at 2 a.m., or pick a slice they are not asked to adopt.
Training will not fix a slower path. A go-live on a festival weekend will not fix it either. Parallel run means the old screen still works while you count how many jobs went through the new one. If you switch off the old screen to force adoption, you are not testing an MVP. You are taking a production risk to protect a project plan. Write that down before you agree a date.
Full rewrite — when it is the honest job
Rewrite when the wrap is impossible, the slices would be the whole system by another name, the vendor is gone, the database cannot be restored, or the application cannot run on any machine you can still buy. Rewrite when two or three slices have already passed their two-week tests and the leftover desktop is a stub. Rewrite when the process itself is changing and the old screens encode a job you are retiring.
Do not rewrite because the UI looks old. Do not rewrite because a hosting company used the word cloud. Do not rewrite because a graduate does not want to read VB6. Those are feelings. They can be true and still be the wrong spend. A rewrite is a custom system. Estimate it like one, with a first slice and a definition of done, on ASP.NET Core if that is the stack, not as a “conversion” that will somehow be cheaper because the screens already exist.
Old screens are a specification of what people actually do, including the ugly exceptions. Read them. Do not guess the process from a manager’s memory and then blame the night shift for “resistance”. The exceptions on that desktop are often the product. If you skip them, staff will keep the old box under the desk. We have seen the under-desk box. It always wins.
A comparison you can put on one page
| Wrap | Replace a slice | Leave it | Rewrite | |
|---|---|---|---|---|
| Night shift | Keeps the old screen | Only if the slice is their job | Keeps the old screen | Must adopt or you failed |
| System of record | Still the desktop / its database | New slice owns one job | Still the desktop | New system, after a parallel run |
| Fails when | You cannot reach the data | The first list grows | You cannot restore, or one operator | You skip exceptions and force a date |
| First test | An export or read that staff do not retype | Two weeks of the assumption sentence | A restore and a deputy | The first slice, not “module one of twelve” |
Access, backups, and the dongle in the drawer
Before any of the four options, you need a restore, a copy of whatever licence still exists, and a note about the machine that can still run it. If the only copy is on a dying disk, the first week is not an API. It is a disk image and a spare PC. Cloud migration will not fix a database you cannot back up. We have said that on the modernisation service for a reason.
If you do not own the source, write that down. A wrap that needs a new field inside the old binary is not a wrap. It is a vendor conversation or a slice that lives beside the old screen. If the vendor is a person who retired to Thrissur and answers the phone sometimes, price their availability as a risk, not as a plan.
Permissions matter as soon as anything leaves the room. A read-only phone view for a supervisor is still identity. A dealer seeing a status is identity plus a guarantee that they cannot see another dealer’s rows. The old desktop often used one shared password on a shop-floor PC. Do not copy that habit into a sidecar and call it modern. The boring security list can wait for another Monday. The rule for this post is simpler: if it is on a network, it needs a person, a role, and a log.
How to brief the next conversation
Write what the night shift does in twelve steps. Write who else needs the same data. Write the last restore date. Write whether you have source. Then write one sentence: wrap, slice, leave, or rewrite. If you cannot choose, you are not ready for a build quote. You are ready for a short modernisation review that ends in that sentence.
If the sentence is a slice, attach the assumption, the in-list, the out-list, and who will use it on Tuesday without you. That is the MVP brief. If the sentence is a wrap, attach the tables the API may touch and the tables it must not. If the sentence is leave, attach the spare PC and the deputy’s name. If the sentence is rewrite, you still start with a slice. Twelve modules on one slide is a brochure.
We will not invent a client who “moved to the cloud in twelve weeks”. The firms that do well pick the option that matches the night shift and the data they can actually reach. The rest buy a new screen and keep the old one under the desk. June is a good month to look under the desk before you sign anything.
If you already know the first job that must leave the desktop — a claim, a dispatch, a status a customer can see — start there. Fund it as .NET work with an MVP shape. Leave the posting screen alone until that job is real. The night shift will keep the lights on. Your job is not to impress them with a redesign. It is to stop pretending a rewrite is the only adult option.