I think you may be biased towards the reasons to replace it, given that it was your creation, and we're not hearing the whole story.
It may well be that the system was difficult to maintain _because_ it used a bespoke framework of vanilla JS and handcrafted SQL Server queries.
Or that they wanted to improve the workflow of importing CSVs, and build modern features around it, which would be a mountain of work.
Or that the company outgrew it and it was difficult to scale.
Or, you might be right, and it was politically and financially driven. But then the technology choice wouldn't have mattered, and you could've chosen a more complex stack just as well.
I appreciate the sentiment of trying to keep things simple and not jumping on the bandwagon of the latest trends, but sometimes choosing a popular framework is not a bad idea. Particularly in corporate environments where the project is not owned by a single person, churn is high, and new developers are expected to eventually take over maintenance.
One day of maintenance per year is not "difficult", that's basically the point!
I didn't use or create any JS frameworks, which is a part of why the maintenance was easy!
The customer was a government department, and their scale changed only with population. That is: slowly.
> sometimes choosing a popular framework is not a bad idea.
Ironically, the replacement product used a popular but out-of-date technologies such as Enterprise Java Beans. They overused OO paradigms to a hilarious degree, and needed something like 2000x the server capacity to host their application.
Keep in mind that the data, userbase, requiements, etc... are all identical. This is a like-for-like replacement.
They needed an entire team of people just to babysit the infrastructure, which now took a decent chunk of a data center. My app could have handled the production workload while running on my laptop.
It may well be that the system was difficult to maintain _because_ it used a bespoke framework of vanilla JS and handcrafted SQL Server queries.
Or that they wanted to improve the workflow of importing CSVs, and build modern features around it, which would be a mountain of work.
Or that the company outgrew it and it was difficult to scale.
Or, you might be right, and it was politically and financially driven. But then the technology choice wouldn't have mattered, and you could've chosen a more complex stack just as well.
I appreciate the sentiment of trying to keep things simple and not jumping on the bandwagon of the latest trends, but sometimes choosing a popular framework is not a bad idea. Particularly in corporate environments where the project is not owned by a single person, churn is high, and new developers are expected to eventually take over maintenance.