Rewrite or...?
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Yeah, but unless you have a very solid plan and strategy that's destined to fail. You don't just rewrite 20 years of development.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Avoid doing a hard rewrite/relaunch, do a gentle "sunsetting" over time 1 Keep the old application but keep track of how many hits it gets 2 Make a new competing application, also tracking its hits Then launch them side-by-side, giving the user a choice about which one they want to use, maybe even having cross links to make them able to "jump to the other side". Keep a look at the statistics to see if the new one is gaining or losing. I think you get the basic idea. Suggested reading: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22[^]
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
You haven't given us any idea how big the system is (in terms of lines of code or whatever). Although, arguably, the bigger it is the more it would make sense to rewrite it rather than having to keep some old, creaking codebase working. I recently went through my entire C++ codebase replacing a lot of old-fashioned manual memory management with 'modern' C++ idioms. It was a daunting prospect initially but I am sooooooo glad I did it. So, I would say, if you can handle the issues that Sander (quite rightly) raises and have sufficient resources then I would go for it. Just my $0.02
Paul Sanders. If I had more time, I would have written a shorter letter - Blaise Pascal. Some of my best work is in the undo buffer.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Having been involved in a big ground-up rewrite (painful, everything takes longer than everybody thinks or is willing to stomach) I would tend to favour an incremental refactoring approach. So (if possible) put the new code in the same site as the old, and start replacing features one by one. I wouldn't envy the person who has to extract that SQL out of WebForms though!
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
others likly given similar response, my basic points WHY, what does client or end user benefit. Developers are not the user that said - if want to reduce COSTS (time or money) for adding features, that a good why for client. Changing underlying code to fix "mistakes" (things that have newer ways, or low quality patterns) Platform compatibility. Main reason had to take a silverlight/lightswitch to HTML. Security issues maintenance vs feature add feature add turn around time and best for client - features that at the time of request could not, or costly to implement can be scoped in this work of redesign. Some of these features might replace existing features thus not need transfering.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I've awoken my old account just to chime in on this as I've had some recent, terrible experience here that might help. I'll try to keep my rants to a minimum. Sadly my last position was working in this tech stack, with over 150 customers using various versions of the product. - Business logic strewn throughout SQL procs, UI and a little bit of mis-informed backend abstractions coupled with embedded and sitewide javascript. - No source control, at all :mad:. - Zero, or inadequate out of date documentation. - Team works on network shares. - Manual deployment. - No IDE or any other tooling (except for SQL Management studio). - Building was done using cmd scripts split into arbitrary "modules" due to the limitations of the command buffer string length. - Versioning on live system was mandated - rename the old file with a date, and leave it there. - Sometime in the past they switched from VB to C# which was the dominant language when I started. The mix led to some awful days where I realised I had to touch the VB, and those days were long, unproductive, usually doomed to fail. Staff turnover (all senior devs) was 100% for new hires, lasting from 4 months to 1.5 yrs (me, the fool). 10 years of constant losses, mostly negative customer relations with some "entrenched" customers buying out the parent company on more than 2 occasions to keep their critical systems from vaporising led to my current attitude to this type of product.. return to the ship and nuke it from orbit. Seriously though, I would park it in a vm(s), charge a fortune for anything that needs change management. "Try" to fix any security holes that are essential, but first try to mitigate those within your new virtual infrastructure if you can first. Product is not cost effective, and the customer needs to understand that through passing on that aspect of the business. If cost is not an issue, maybe think about selling it on to an outfit that doesn't mind/understand financial loss, the technical debt or the talent attrition it will cause :suss:. You mentioned updating the html/css and providing a more modern approach to responsivness. The product I worked with had all that already and still had the above issues. My opinion is that it will not improve your developers lives, nor maintenance timescales, but might reduce the front end developers attrition in the long run. It might also increase the appeal of the application to the customer, making it seem "better". Do you really want that? Moving to C# might seem like a good plan, b
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
One very good and not-going-to-flip-the-canoe improvement might be Flyway. The learning curve to some very basic "make sure my database state is what I think it should be" is not at all steep, but there are also some nice to haves if you dig deeper. You essentially version control your DDL/DML into numbered scripts which it then facilitates applying to a given database by checking to see what was the most recent one applied and applying anything newer. A nifty option (that you have to also create if you want) are undo scripts correlated to the "do" scripts that allow you to rollback the change made by the "do". This marries into build/release pipelines in easy and good ways. For an Azure DevOps build pipe, you might first have a commandline step "clean my database and start over so nothing is funky from a previous mistake or someone mucking around because it is the build box". In both build and release ADO pipes it is another commandline step added to flyway migrate the db. You could deploy and run the flyway scripts and flyway infrastructure required to run them (a bunch of java) from the artifact project folders being deployed if you wanted to. Typically, we don't do that, opting instead to deploy and run the migrations from a totally different environment. We do this partially because there would be multiple service hosts in a deployment group and you only need migrations to run once. While it's not a huge bunch of more binaries/data to throw out there, on all but one machine it would generally exist for very little reason. "LINQ queries are a pain in VB!" I'd forgotten that particular horror, thanks.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I think this would depend very heavily on how useful and unique the program is. Back in the day, I was a co-operative education engineer (sort of a paid intern) at a company that had a flight simulator that they ran in this huge sphere of a room. It was a massive thing that cost vast amounts to run. Our boss tasked me and one other co-op to convert - or at least begin to convert - the program to a c version to be run on an x terminal. It was lots of fun with very little risk involved for us or them (we were just interns after all). I don't know if the project was ever completed, but we got a really good start on it. The question is whether it was finished before the plane it was designed to simulate went out of production. So, you see, it all depends on value for work, same as every other project undertaken.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
In short, without getting detailed: Refactor. 1. Isolate and extract business code, and if it contains SQL, change it to stored procedures. 2. Translate (using online tools) the VB to C#. 3. Refactor the C# as necessary to be object oriented. 4. Capture the HTML and CSS for use in Blazor Client. 5. Isolate the UI logic that was JavaScript or VB, convert to C#, and use in Blazor for the UI layer. 6. Convert any C# code necessary from .NET Framework 4.8 to be compatible with .NET 6. 7. Start debugging and get it working with no new features yet. 8. Once what you have is working, then add any new requirements.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Scope...Scope Best practices, on web especially, tend to lean towards the concept that your site is going to be the next viral app. A low volume site will generally outlive the technology behind it. Having 5k users today doesn't mean you'll have 50 or 500k next year, or anytime in the future. So, I'd want to look at traffic, and make some decisions based on that. Really, I'd roll back the entire look to see if .Net is the best choice for what you're looking for. Since I'm about 67% desktop development, I've been tempted to try .Net on the web, but use LAPP/J-various on the web side of things. (And it's way cheaper and easier to maintain) That's just me though. We're re-writing 25yr old VB6 desktop code and it starts out as fun, but goes downhill from there. :) Not knowing how deep the site is, it's tough to make a really good call. Also, how deep are your customer's pockets? I think this might be a good start:
Quote:
Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive.
since in any case it's going to need to be done as part of any upgrade and won't be wasted effort. Your client may be more responsive to a multi-step approach. Been too many years since I've looked at SQL Server to comment on that part; heck, I don't even know what
Quote:
SQL queries written directly into the HTML
means, lol.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I have a similar situation. Code is in classic ASP. Best approach is to get the rules as they SHOULD BE from the business owners if you can. If not, at least document the screen level functionality. When you feel comfortable, create a road map . Take one piece at a time. I would start by identifying what could be converted to a service prioritizing what is re-usable first. (Authentication/Authorization would be a good start) For ease of maintenance alone, I think a rewrite is in order. The longer the client waits, the larger the risk of something being deprecated in a future release.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Our company has an enormous monolith that shares a lot of similarities with this situation. While we are currently road mapping a full migration/rewrite, in the mean time we were able to get all our Sql stuff into source control by generating "create/alter" scripts for every procedure, function, view, and table. So while we still have tons of logic in Sql, it is at least source controlled. This might be a helpful first step, regardless of what happens next, since doing so gives you all the logic for those parts in text files.
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Sander, I think we have agreed on a few things in the past... First, the "Lack of source control for the DB can be fixed with some extraction tools". I do this today, and commit them (In production systems this has saved my clients). I automate it to push the changes up nightly from production. And I use the technique in dev, and simply DIFF the the Branches. Anyways, I would SLOWLY rewrite the code to C# using modern approaches. In the end, I am not sure I would want all the business logic ripped out of the DB (unless they have a goal of replacing that)... And I would implement things in C# that the VB.NET could call like an API, until you get the chance to replace it with C#... This way, it is slowly migrating away from stagnant... And I would certainly push to train all the developers to use C# for new features. There is still a Big Cost here... But it should be easier to absorb. In the end... It's just code!
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Am in a similar position, but with an app written only about 8 years ago; VB.Net, ASP.Net webforms - but well-structured, multi-layer code, all D/B access via SPs, minimal logic in the SPs. Just trying to find WebForms developers to support going forward is the hard bit. Plenty of people with Webforms experience, but none who want to use it! I have "cloned" the application for another customer, converting to C# along the way (using online tools to automate). A certain amount of manual review needed but on the whole that was the easy bit. Doing it page-by-page (depending on how your site is configured) may not be possible - mine's setup as a WebSite (not a web application) and I don't think you can mix languages in that environment. Probably best to start with a language swap before then tackling any changes / updates; otherwise you've just got more - and less "mature" code - to convert. Depending on current structure it might be worth rebuilding one layer at a time - i.e. building a "modern" DAL and moving the SQL well away from the presentation layer. Update the production system at each major milestone rather than leaving it to a big-bang replacement. As others have said, the biggest hurdle is probably convincing the business of the benefits of all this work. Might be worth identifying any known bug-bears for the users and ensuring those are addressed early on so they are invested in getting the new version implemented. Similarly not bothering with "improvements" that don't deliver value to the users - e.g. no point in responsive pages if all the users are in the office on 24" screens. Sure you've considered all this and more anyway! Good luck...
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
-
So I have this customer who has this 20 year old web application. It works, it's still actively developed, but it's beginning to show its age (well, I guess it's been doing that for years). It's VB.NET Web Forms updated to the latest .NET Framework, 4.8. It's pretty much what you'd expect of something like that. SQL queries written directly into the HTML (or whatever you call the Web Forms HTML), a lot of roundtrips to the server, and XML web services. Most logic is written in SQL Server views, functions and stored procedures, which don't really have any sort of reliable source control. A lot of programmers wouldn't touch it with a stick. Now there have been discussions over whether or not we should do a rewrite, or in any other way update to something more modern. Maybe we can start by modernizing the generated HTML and CSS to make things more modern, like making the pages responsive. Replacing VB with C# would be a good move to attract developers in the future and to make use of newer language and VS features and we can hopefully do that page by page (for example, LINQ queries are a pain in VB!). Perhaps throw in some build and release pipelines (it's now copy/paste) and replace SVN with Git. I know rewrites are hard, expensive, and probably more often than not don't end well. Have you been in this situation? What did you do? Tips?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
In June I retired a desktop/web app originally written in the late 90s, looks like VS97 from the style, but the vendor re-vamped it in every version of VS up through 2010. The last few years have been support hell, both on my side (customer) and for the vendor. Continued development in a 20+ yo technology that is no longer supported is expensive, and it gets harder and harder to find people capable and willing to work in that technology. Having people retire (or die) and being unable to replace them in a real problem. Replacing the application is going to hurt at some point, and the longer the customer waits, the more painful it is. I analyzed what the old system did. Listed all the functions, process flows, etc. This was a 9 month effort of a system with LOTS of intertwined business rules. Next I reviewed the functionality with the customer, including walking through the existing application, and updated the requirements to reflect fixes and some enhancements. Finally, I produced a detailed design, then we started building. It was not a smooth process, but we made it happen. The old application required Internet Explorer (I said it was built in the 90's!), and we got the new application in just before MS officially sunsetted IE. It really helps expedite decision making when there is a hard, immovable deadline. :laugh:
-
> but it's beginning to show its age That is a vague problem description. What is the real problem? - performance, - concurrency, - GUI (look & feel) - quality of code, - no people that know the technology? - ....
All of the above. People know the technology, they just don't want to work with it (including me, to be honest).
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Avoid doing a hard rewrite/relaunch, do a gentle "sunsetting" over time 1 Keep the old application but keep track of how many hits it gets 2 Make a new competing application, also tracking its hits Then launch them side-by-side, giving the user a choice about which one they want to use, maybe even having cross links to make them able to "jump to the other side". Keep a look at the statistics to see if the new one is gaining or losing. I think you get the basic idea. Suggested reading: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22[^]
It's an internal business application. No competing or statistics there, just the one or the other.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
