How to Successfully Rewrite A Web Application
A Live Workshop by Tony Alicea
You're about to start rewriting a web application. If your first step is to choose your technology stack and start estimating features: STOP, you're doing it wrong.
You're potentially about to waste a lot of time and money. You have an amazing opportunity in front of you. Don't waste it.
This live online workshop will show you how to approach rewriting a web application in a way that results in less software, less technical debt, less complexity, less investment, and happier users and developers.
This workshop is for you if you are working to:
If any of these are you, then this workshop is designed for you and your team.
A rewrite of existing software is an expensive and risky undertaking. You may be dealing with nervous users, anxious stakeholders, and scope creep as your devs work through the existing app.
This workshop will help you save days, weeks or even months of work. The benefits are many, such as:
Here's the big lie of software rewrites: "The requirements are already there in the existing software." This simply isn't true, and it sets you up for failure.
The big mistake of software rewrites is to say: "Let's analyze the existing software and start estimating copying the features." This is a massive waste of opportunity that results in unnecessary technical debt, expense, and possible failure.
When you choose to do a "tech lift" or "port" of an application, rewriting it screen-for-screen, feature-for-feature, you don't just port the functionality. You also port:
...among other things. No one was using the app when it was originally built. Why would you depend on that lack of knowledge as the basis for a rewrite?
You will learn how to do better.
This workshop will teach you a complete approach for successfully rewriting a web app, that starts far before picking your tech stack.
You'll learn to:
The workshop is broken into 5 major areas.
Existing software is free user research. Analyzing and observing how users use existing software teaches us the "cow paths" that users take to get their work done, often working around the software not with it.
Stakeholders may think they know the requirements of the software. But by observing users we can arrive at a better understanding of what the software actually needs to help users do, or prevent users from doing.
You can take the workarounds people invented for the old software, and make them the basis of requirements for the new software. Your users will thank you.
Rather than thinking in terms of existing features, you can learn to think in terms of the problems the existing features is solving.
You may find that one feature solves multiple problems. You may find some features aren't needed at all.
By "whying down" the old app, you often end up saving time and money on a rewrite.
Thinking in terms of frequency-of-use is a usability super power.
By analyzing how users are actually using the software, you can tell which features need to be tailored for speed-of-use (for power users) and which need to be tailored for ease-of-use (for clarity).
The old software is a treasure trove of usability and workflow research. Treat it as such, and you can design new software that users welcome with open arms.
Choosing a tech stack in the modern web development world can be a huge challenge.
That challenge is made much easier when the groundwork is laid from the areas we've just discussed. You can then apply the knowledge of what problems need to be solved and how users are really using the software to choose your stack.
You may even find that entire feature sets can be replaced by trusted 3rd-party tools or services. With a proper rewrite, custom features can become integrations that save time and money.
For features that need to be custom built, having a clear picture of what needs to be designed helps make sure you choose a stack that will match the needs of the software.
One massive release, replacing an entire web app, can be a nightmare.
By forging relationships with early-adopter and trainer personalities amongst users, you can adopt an iterative beta-release mindset, and even have users do double entry if necessary.
Iterative releases based on what I call the "Minimum Solved Problems" approach deliver useful features in a way your team can reasonably handle.
The cost of a seat to the workshop is less than you'd pay a few devs for a day of work. If you rewrite a web application properly, you'll be able to save a lot more than that.
Hi, I'm Tony Alicea. I've been an application developer, database architect, UX designer, manager, and tech educator for over 25 years. I've run countless all-day and multi-day live online workshops.
Over 350,000 students have enrolled in my courses on Udemy, Pluralsight, and Teachable (where this course is hosted). I've been a speaker at conferences like React Summit, the biggest React conference in the world. You can read more about me and my courses on my site.
Most importantly, I've worked on the rewrite of many legacy applications, including some with hundreds or thousands of users. I'm excited to bring the benefits of that experience to your project, and help you save time, money, and frustration.
Save time, money, and frustration by rewriting your web application properly.
$900 $1200
25% off early bird seats.
Get notified when seats go on sale.
INCLUDES