If you're wondering what this is all about, consider yourself fortunate. Many brave men were spent for this cause.

Imagine a client whose data is extremely valuable, to the extent that some systems are kept offline. Sometimes this is due to legal requirements, sometimes it's due to security issues that are not intended to be solved, and sometimes there might not even be a reason.

Dreams are SaaS, and the reality is on-prem. There's a lot more on-prem software in your life than you might think. The journey can continue on-prem when a product that starts as SaaS catches the attention of enterprise customers. Anyway, on-prem software exists. Don't say, "I don't work with these." Bad words have a way of coming back to haunt their owners.

Now, let's get to the problems:

Do you know what it means to plan a release cycle? Setting deadlines for patches, writing release documents, maintaining a known-issues document, and assigning custom support personnel to customers. These are all painful tasks.

Customers are still using old versions, some are old, some are very old, and some are completely forgotten. Some don't even know what version they're using, and some can't even configure their own servers. Understanding what a problem is, starting with a simple "There's an error," can sometimes take weeks.

Imagine encountering a problem that only exists in an old version. How difficult can it be to fix this problem? Hopefully, you have the branch of that old version in your hand. But don't celebrate too soon. Understanding the old version is harder than understanding the current one. You may have made architectural changes or design pattern changes. Let's say you somehow fixed the error. How will you test it? By setting up a new environment? What if you can't access the other old version packages that the old version used to work with? What if you can't even access the operating system of that version? What if the error is caused by corrupt data? Can you mimic the user's old use habits? Can you find a developer who wants to deal with this? Even if you find one, will they want to do it multiple times? This situation can ruin a developer's sleep and a cool software company's atmosphere.

Changes in the database are endless. New columns come, old tables go. NoSQL won't save you. When transitioning from an old version to a new one, compatibility issues with old records can occur. Some clients who moved to the new version may want to use the old version because they like it. Is there a way to make the customer's database usable? There is!

Jumping through hoops to access a log file. The first place to look after hearing "There's an error." Users who don't have permission to access the log file, users who share the log file as a screenshot, and security-obsessed users who share a few lines of the log file. Getting that log file is not a task for everyone.

Blaming your application for Single Sign-On (SSO) issues is a tradition. Users who can't access the application immediately blame your application. A user who can't even access their email won't admit that they entered the wrong password.

You should remain calm when you realize that most of the problems prioritized as urgent are not actually urgent. The person trying to find a solution to a support ticket opened as "urgent," drops their work, only to find out that the person they are helping didn't attend the meeting, doesn't remember the problem, and is even on vacation. They might consider quitting software and becoming a farmer.

A system administrator going on vacation can lead to a situation where all your work is disrupted. You may need to adjust your work according to a respected person's absence because a highly secure and corporate customer is working without backups.

It's quite normal for you to be blamed when changes are made in systems you're integrating, and you're the last to know. Users kiss what they catch first.

Are there no problems at all? Is everything going smoothly? Well, here are some performance issues for you. Work piles up on the customer side, and it keeps piling up. Then the accumulated work comes knocking at the door. A corporate customer tells their staff to finish the work immediately. All users overload your application. With a tiny amount of RAM on a small virtual server, the corporate customer expects your application to run. The programmer who says that the RAM is insufficient is immediately given a lecture. "You're the only one with problems with your application; our system is very robust..." The programmer looks at the wall and thinks that farming is actually a nice profession.

You can't get data on how the software is being used. How users are trying to solve which problems remains a mystery.

Perhaps you'll be lucky enough to leave this world without developing on-prem software if you become a good smurf.