8 ms·

From my experience of doing a full migration of a not too large frontend app, its gonna take way longer than anyone expects. And there are going to be higher up

From my experience of doing a full migration of a not too large frontend app, its gonna take way longer than anyone expects. And there are going to be higher ups that are going to be upset about it, because whoever sold them on the idea of a full rewrite, said it would take x but its taking 2.5x or how ever long it takes.

bruce511 2y ago
I concur. On that line; You can select a release date. Or you can select a release feature set. You can't select both. Since you've already got a feature set for your primary client and a release date, you're already under time pressure. That doesn't bode well for success. Time pressure means you optimize for "done" rather than "done right". Which means you cut corners, will "come back and fix that later" (which never happens) and in 5 years you're back where you started. I rewrote a big DOS system in Windows and it went well. Primarily because; A) there was no "backwards compatible" goal. (We could import user data, but configuration was very different, and not portable.) B) the -experience- of working on the dos system had given me insight as to where the bottle necks and problems were. So the -design- looked at those problems and made them go away. That program is still going strong 25 years later (and has been under continual development all that time.) Because the foundational design is right, it's been added to coherently and none of it is too-brittle-to-work-on. My point is that this is a "generational change". Getting the design right will be worth years of revenue at the other end. Your bosses domain knowledge is key. Coupled with their experience of what works well, and what works badly (code no one wants to touch, regular support issues, features that can't be implemented etc.) 90% of my regrets are around data design. We used numbers as primary keys (pretty normal for the 90s as space, ram and cpu were limited). But that has made some tasks much harder now (database merges, distributed data etc). Today I'm a strong advocate for UUIDs (especially UUID7). Personally I like the different-database-per-customer approach. It's better for security, and allows us to copy production data for support and development. It also scales better. (Ie horizontal scaling). Since the original program ran local, each client had their own database anyway. We mitigated upgrading hassles (a BIG issue in the DOS system) by making the program itself upgrade the database. (It checks, and runs upgrade tasks on startup.) One big advantage of this approach is that we can roll out upgrades slowly (one client at a time) when we're doing big changes, and upgrading one client doesn't bring down others. But those are problems and solutions in my space. They may not be appropriate for your context. Each design decision is a trade-off, understanding the upside and the downside of each one in the long-term is key to making the right choice for your context. Sometimes hedging your bets pays off too. For example you can populate your database with tenentID fields. You can code as if for multi-tenent. But you can deploy as one tenant per database. That approach gives you flexibility later on. Good luck. It sounds like a fun project. But this foundation will ultimately determine how long this generation of the software is good for. Don't rush it. Gather as much information from your bosses as possible. Present design options and implications - but ultimately get their buy in to choices made. They need to understand the pros and cons because you'll inevitably hit a con one day, and it's best if they understand its a decision they made, not you.

bruce511 2y ago

I concur. On that line; You can select a release date. Or you can select a release feature set. You can't select both. Since you've already got a feature set for your primary client and a release date, you're already under time pressure. That doesn't bode well for success. Time pressure means you optimize for "done" rather than "done right". Which means you cut corners, will "come back and fix that later" (which never happens) and in 5 years you're back where you started. I rewrote a big DOS system in Windows and it went well. Primarily because; A) there was no "backwards compatible" goal. (We could import user data, but configuration was very different, and not portable.) B) the -experience- of working on the dos system had given me insight as to where the bottle necks and problems were. So the -design- looked at those problems and made them go away. That program is still going strong 25 years later (and has been under continual development all that time.) Because the foundational design is right, it's been added to coherently and none of it is too-brittle-to-work-on. My point is that this is a "generational change". Getting the design right will be worth years of revenue at the other end. Your bosses domain knowledge is key. Coupled with their experience of what works well, and what works badly (code no one wants to touch, regular support issues, features that can't be implemented etc.) 90% of my regrets are around data design. We used numbers as primary keys (pretty normal for the 90s as space, ram and cpu were limited). But that has made some tasks much harder now (database merges, distributed data etc). Today I'm a strong advocate for UUIDs (especially UUID7). Personally I like the different-database-per-customer approach. It's better for security, and allows us to copy production data for support and development. It also scales better. (Ie horizontal scaling). Since the original program ran local, each client had their own database anyway. We mitigated upgrading hassles (a BIG issue in the DOS system) by making the program itself upgrade the database. (It checks, and runs upgrade tasks on startup.) One big advantage of this approach is that we can roll out upgrades slowly (one client at a time) when we're doing big changes, and upgrading one client doesn't bring down others. But those are problems and solutions in my space. They may not be appropriate for your context. Each design decision is a trade-off, understanding the upside and the downside of each one in the long-term is key to making the right choice for your context. Sometimes hedging your bets pays off too. For example you can populate your database with tenentID fields. You can code as if for multi-tenent. But you can deploy as one tenant per database. That approach gives you flexibility later on. Good luck. It sounds like a fun project. But this foundation will ultimately determine how long this generation of the software is good for. Don't rush it. Gather as much information from your bosses as possible. Present design options and implications - but ultimately get their buy in to choices made. They need to understand the pros and cons because you'll inevitably hit a con one day, and it's best if they understand its a decision they made, not you.