Robert, I am just taking on a project for a similar situation: v11 to v17. I haven't had a chance to really dive into the code yet so I'm not really sure what's there but at this point the client's intention is to essentially keep the database on 'palliative care' for the next 1 to 2 years when they migrate to another platform. Given their needs at the moment a re-write isn't in the cards.
In another project, one I started in v6 and maintained for the past 15 years, I have performed two 'greenfield' re-writes. The first was going from v6 -> v2004, the second v2004 -> v13. In both cases the re-write was necessary to correct structural design issues. This project grew in scope quite a bit and changing the basic data structure made it easier to continue to grow as well as leverage 4D's new capabilities. Looking back they were the right decisions at the time but especially the second migration was a lot of work. And in both cases the data had to be dumped from the old structure and imported into the new one with different levels of transformation required. This is not a bad thing. Especially in bespoke projects the data can become munged up with structure, interface elements and this is never a good thing. It's always a result of some momentary expediency and over time becomes increasingly detrimental. You know the question we are talking about here is what's called 'technical debt' and there are a ton of things written about it. I've been reading a few of them lately as well as talking with other developers about it. 4D is particularly ripe for these discussions because of the backward compatibility it has so rigorously embraced. The fact there are still so many critical systems running geriatric versions of 4D proves this point. The final straw that's moving the client I mentioned to act is the system has been running on a single computer for years, the person who wrote it has retired and the computer, the hardware, is showing signs of failing and no one in the organization knows how to deal with 4D. This isn't an unusual story in 4D land. So now we come to the business question - can you just keep it working for another year or two? For better or worse the answer is yes. I don't know what I'm going to tell them it will cost to do that yet but it's certainly a fraction of what I'd quote for a rewrite. Is that a good thing overall? Schmaybe. As a business principle would 4D loose some clients if there were limits on the perpetual backward compatibility. On the other hand we wouldn't be seeing v17 databases running code so old you just need a black background and a gold colored, pixelated font to believe you're working on an old VT100. It's hard to convincingly talk about how modern 4D is when you're looking at that on the screen. Bottom line - a re-write is a hard sell. It's a hard sell in any case but especially for 4D precisely because we've been around so long the perception (Perception) is the technology is old. It's not but the IT guys sitting in the room who only know about it as this PITA system they don't understand and can't get rid of are not going to embrace it. What we, developers, can do is be more like 4D. Like v17 4D. ORDA is essentially a new programming language within the 4D shell. (I know there are some strong voices saying this isn't true. Flame on.) I didn't think such a thing was possible or that I would ever see it. I was wrong about that and I'm delighted. The old bones of 4D are still there and available but there are new options as well. I suggest this is the model we can extend to modernizing old projects. Namely, instead of staking out large swaths of green fields and building from scratch (think Albuquerque) move the existing tables over to the right and build on top of what you've got (think Rome). I tend to start with the overall approach to displaying data. The existing project probably uses a lot of MODIFY SELECTION and MODIFY RECORD. This was fabulous in the day but you can do better now. So do it. Structural issues can be identified, solutions developed, tables added and the relevant data migrated within the current structure. There are some real benefits to this approach not the least of which being if something goes sideways you can roll back to the old data by rolling back the structure. There is plenty of time to purge the datafile once you have certainty the new approach works. It is important to clear the old data AND the obsolete code. This second point is really important because if you don't periodically identify and remove obsolete code then this "build on top" approach spirals into unmanageability. Or at least a structure where you may have a few thousand methods but only a few hundred actually are used. The point is we can modernize and migrate a mature app on top of the old structure. This allows us to make incremental changes, particularly in the user interface, that can revive a project. On Wed, Oct 17, 2018 at 12:45 PM Robert ListMail via 4D_Tech < 4d_tech@lists.4d.com> wrote: > I have an old v11 database running on Windows that’s not particularly > well-designed and where there are more than a few subtables to deal with. > Assuming that there is no additional budget for writing a new clean app, > would you likely upgrade or re-write in v17 with the old v11 structure as > guide? I’m concerned that the upgrade path will be difficult because of > the subtables and that by the time you deal with all of the legacy junk not > this database from the early 90s you could have created something fresh and > new. How might you approach this? > > Also, the client originally said the new database would not have to > migrate data forward from the old system and now they are wanting to have > the data too. > > Thanks, > > Robert > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
