Moving a legacy app to the browser in 30 days

Replacing a legacy application is a project measured in years and politics. Changing how people reach it is a project measured in weeks. The two are different, and the second is the one you can do now, while the first stays on the roadmap where it belongs.

Here is a plan that has the right shape for most small and mid-sized teams. The dates are a guide. The order is the point.

Week 1: inventory

Write down what you are actually dealing with. Which application, which version, how many users, which devices. For each user, how often do they open it and for what? Most teams are surprised by how few people use it daily and how many use it twice a year.

This is also the week to settle the questions that can end the plan before it starts.

• Does the program need hardware plugged into a local machine, such as a dongle or a scanner?
• Does it depend on heavy graphics?
• Does its licence allow it to run on a host, and under which terms? Windows needs a valid licence too.
• Where does it keep its data, and what does it connect to?

Week 2: pilot

Move one application for a few people, and have them do a real task from start to finish, including printing, exporting and anything unusual. Not a demo. A Tuesday.

Choose the pilot users carefully: one enthusiast, one sceptic and one person who uses the program in the oddest way you know of. The odd user finds what the other two will not.

Week 3: controls

Before you widen access, decide who may do what. Sign people in through your identity provider if you have one. Give each person a role. Decide whether the clipboard and file transfer are open, closed or limited, and whether sessions are recorded. Tell people what is recorded and why.

It is far easier to start with sensible limits and loosen them than to tighten a free-for-all after the fact.

Week 4: roll out and retire

Move the remaining users in groups, not all at once, so that support stays manageable. As each group moves, uninstall the local copy. This is the satisfying part, and also the part that makes the saving real: until the installers are gone you are paying for both.

Finish by writing a short runbook: how a new person gets access, how a leaver loses it, what to do when the application is slow, who to ask. One page is enough. It is what keeps the arrangement from reverting.

What usually goes wrong

• The pilot is skipped, and the surprises arrive during rollout.
• A licence restriction is discovered in week three.
• Printing and file exports were never tested.
• People keep their local copy 'just in case', and the old habits survive.

Thirty days will not remove a legacy app. It will remove the installs, the shared logins and the laptop copies, which is most of the pain. The replacement can wait until you know exactly what you are replacing.