Skip to Content
Personal Insights
Author's profile photo Michael Keller

Software and technologies from the past. Really dead?

Dear community. Lately I’ve read over and over again that this software or that technology is dead. That kept me busy. I’ve thought about it for a while.

For a start, I don’t like the expression “dead”. In the context of software or technology, I don’t think it’s a good word. But that’s my very personal opinion. Perhaps it’s used too frequently and too quickly. Terms like “obsolete”, “outdated”, “without further development”, “only in maintenance”, all fit better for me – but not the term “dead”, please. Unless it’s really true 🙂

That being said, the use of this term implies to me that software or technology has disappeared. It only lives on in memories. Recorded on screenshots, in books, in documents or other media.

In practice, it often looks different to me, at least in many cases. Let’s take my favorite example: SAPscript. Declared dead a thousand times. I still find it in historically grown systems. And it’s still used. Even new requirements are constantly being implemented. If this old technology were dead, it shouldn’t happen. A SAPscript form should have been converted to a modern technology such as SAP Interactive Forms by Adobe long ago. Maybe about 10 years ago? Actually, it should already be a Smartform. Since around the late 90’s?

But it probably will never happen. The reason could be that such a project is difficult to sell. Whenever I talk to someone about converting SAPscript forms, it’s obviously about costs. After all, a lot has already been invested in the existing SAPscript form in the past. If you now switch to a new technology without needing or using the advantage of the new technology, nobody cares.

Let’s take the printing of an invoice as an example. Regardless of whether it’s printed via SAPscript or another technology, the information on the form remains the same. Ideally, the output on printer looks the same. No advantage can be seen by the user from the operating department. Why should he or she spend money for a technology change?

That is why this printing technology is not “dead”. It is no longer used to develop a new form. That’s true. Or hopefully that’s true. But existing forms are being developed further. So “dead” is the wrong expression for me. However, the correct expression will definitely be something like “outdated”. And “outdated” can mean that this technology can still be encountered in everyday life. Simply ignoring is often not possible. After all, the technology has a meaning for the customer.

That was a little excursion in my thoughts. How do you think about that topic? Is there “dead” software or technology that you often come across? How do you deal with it?


Best regards, thanks for reading and please stay healthy



P.S.: Not tired of reading? Explore the Google Cemetry.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Lars Breddemann
      Lars Breddemann

      Wow, this topic can go far and deep in any direction.

      What are reasons for holding on to established (legacy) systems? If it were just that the costs to replace it with something modern are not outweighed by the benefit then developer life would be so much simpler.

      How about: nobody knows how the software works in detail, so rather not touch it?

      There's a whole branch of our industry, just concerned with dealing with this problem.

      Even more worry-some: the processes requiring the functionality seem unchanged if a 1:1 replacement would actually be adequate. This is barely ever the case.
      Yet, the old system is kept alive (hurra to virtual machines that can still run the old Windows version that supports the obscure but mission-critical tool from 1997 ...) and workarounds for shortcomings are brought in instead.

      In my view, the major driver for new software is being forced to get new software.

      Whether it's de-support from the vendor, new legal/regulatory requirements, or simply that the overall environment and market expects it (online shop,  email, chatbot). The "innovators" with the radically new business model and the need for new software are rather rare.

      Co-incidentally I came across this very interesting twitter thread (

      Might be interesting for folks that read blog posts like this.



      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      Hi Lars, as always, a pleasure to read your comment. A blog is always the cornerstone. Readers have to add their thoughts and opinions, then it will be an interesting unit.

      Thanks for the Twitter link. From my experience: Kris is right. This is what my everyday life looks like. In this context, a blog of mine fits. The situation is as it is. I can do little about that. How I deal with it is up to me 🙂


      Author's profile photo Lars Breddemann
      Lars Breddemann

      Nice plug for another nice post! 🙂

      And I just realized that your posts are fundamentally different from the stuff I write; yours are much more suitable as discussion/conversation starters. Much more open to commentary.

      My posts are more written for myself; to work&think through a topic/puzzle/issue and keep the result of that process somewhere.

      Differences in style and purpose of blog posts like this definitively support my view that the "long-form content" is not dead (see what I did there?) at all. Looking forward to reading many more interesting posts.


      Author's profile photo GED HURST

      I remember a mantra we always used to repeat to ourselves in the early days of our SAP project (and still repeat even now) : "we are not a software house". This (mostly) stopped us attempting things that were too big or complex, and also means that, yes, we do have old SAPscripts and other old outdated custom software that still perform in a zombie-like way.

      That said, we did have to convert all our old Jetforms to ADS as long-term preparation for S/4 HANA 😉

      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      Great, finally someone introduced the term “zombie” ? Here are some information about JetForm. Please report from your project of converting from old technology to Adobe Document Services. A real-life example is always interesting and sometimes a good story.

      Author's profile photo Werner Dähn
      Werner Dähn

      While I never use the term "dead" myself, mostly for the reasons you expressed, I have to admit I can relate to it in the context of software. Dead means there is a corpse, it is not going anywhere, it does not adjust to new realities.

      That sums up the properties of quite some software and frameworks. Visible on the WebPage, maybe even sold, but not getting bug fixes or adjustments to work with new OS/database versions, less growing in functionality.

      "Zombie" has a nice touch as well 😉

      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      That's a good point. And a real festival for all fans of IT security 😉

      Author's profile photo Manfred Klein
      Manfred Klein

      How about Golem? A Zombie decays and leaves incredible stench. Also ceases to function one day all by itself.

      A Golem is also completely out of time and does it's same movements for all eternity. Unless destroyed. It pays no attention to where it is. If you put a smithing golem into glass or porcelain business, enjoy the show. If you put it somewhere hidden it wont be noticed. Not even smelled.

      If you turn up with 'unrealistic'. A Golem is not more Phantasy than a Zombie.

      Author's profile photo Florian Romberger
      Florian Romberger

      Hi Michael,

      that's a really good discussion. I'm also often asked what about the current technologies. Do you know if some of a SAP guidelines exist which technologies should be used in the various areas:

      • Backend (ABAP expression oriented, I guess my documentation of choice is the ABAP documentation right?)
      • Frontend (SAP Fiori and UI5, WebDynpro ABAP with FPM?, Classic Dynpro?)
        • Frameworks RAP / CAP
      • Printing (:-) this discussion)
      • Interfaces (IDocs, RFC, Webservics or only REST-API's?)

      Thanks in advance.



      Author's profile photo Michael Keller
      Michael Keller
      Blog Post Author

      Hi Florian,

      not easy to answer, but:

      1. Backend: CDS ABAP and pure ABAP via ABAP OO
      2. Frontend: SAP Fiori Elements via RAP
      3. Printing: Adobe Document Services
      4. Interfaces: No single/clear recommendation. You mention all typical/common interface technologies except OData and plan files.

      Discussion is endless and often strictly tied to the level of ABAP stack you are working.