Almost every Polish company with 15 years on the clock has some application that everyone is a little afraid of. The owner's cousin wrote it in Access in 2011. Or an external freelancer built it in WinForms in 2014. Or "that intern lad". It works. It runs the business. And for a long time now, working around it has been taking more effort than actually working in it.
This piece is about a decision most SMEs put off about five years too long: what to do with that app. Each of the three paths — maintain it, rewrite it from scratch, or replace it with off-the-shelf SaaS — has a moment when it's the right call, and a moment when it's a mistake.
Signs the old app is starting to cost you
Nobody wakes up one morning thinking "today we rewrite our warehouse system". The moment arrives quietly, as a string of small symptoms. If you recognise three of these in your business — this topic is real.
- The app only runs on one specific computer in the office (usually an old one), because "it won't start on the others".
- Every Windows update breaks something — printing, PDF export, the database connection.
- Nobody knows where the complete source code is anymore. There are two zip archives with different dates and no one can say which one is current.
- People in the field can't use it because it needs an RDP back to the office, or a VPN that half the team associates with "the thing that doesn't work in the afternoons".
- Every small change — a new printout layout, an extra field, a different order status — costs 30 hours of work from an outside firm because no one remembers how it was built.
- Onboarding a new hire to the app takes two days just to make it run on their laptop.
If you keep delaying a simple change because "Maciek said don't touch this" — that's the moment. The app stopped serving you; it now dictates what you're allowed to do.
Three paths: maintain, rewrite, migrate
In SME reality there are exactly three sensible answers. There is no fourth, even if consultants sometimes try to sell hybrids.
- Maintain and refactor in a controlled way. The app stays, but you reconnect it to a current stack, give it tests, documentation and fix the 2-3 most annoying bugs.
- Rewrite from scratch. You throw out the old code and write a new application that does the same thing, but on a modern stack (e.g. .NET 8 + SQL Server + browser).
- Replace with off-the-shelf SaaS. You give up on owning the software, buy a ready product and migrate data and process into it.
Each path costs differently and gives you something different. The choice is not a matter of taste — it's a matter of how much your process differs from the rest of the market, and how much that app is genuinely your competitive edge.
When maintenance and a light refactor make sense
Short answer: when the app works, is relatively simple, and is unlikely to change much in the future. Typical case: a small Access register with two tables and three forms, used by two people in accounting. Rewriting that on .NET would be overkill.
Refactor makes sense when:
- The app is small (a dozen-or-so screens, one simple database), and the process it supports is stable and you don't plan to change it.
- You have access to the source code and at least one person who understands the technology.
- The cost of a rewrite would exceed a 3-4 year maintenance budget.
- There isn't yet a sensible SaaS alternative for your niche.
In this scenario you invest once in a proper tidy-up: source control in Git, a test database copy, a prioritised list of known bugs, and one or two fixes that hurt the most. Cost: typically 60-150 hours of work. Result: peace and quiet for the next 2-3 years.
When a rewrite makes sense
Typical case: the app is the operational core of the business and it differentiates you from competitors — because it does something no off-the-shelf system does the way you do. Examples: a custom configurator in a metalwork shop, an in-house bonus calculation system for sales reps, a route planning tool for contract logistics.
A rewrite makes sense when:
- The app genuinely supports a process that is your edge — and you don't want to standardise it to someone else's SaaS.
- The stack is so old that yearly maintenance now costs more than the amortised cost of a rewrite over 3 years.
- It's missing things that are today's baseline (working from home, mobile, API integrations with the accounting system, KSeF export).
- You're sitting on bus-factor 1 — one person knows that code and they will leave or fall ill, and you'll be left with a .mdb file and a Post-it.
One of our clients — a 24-person packaging factory near Konin — had a production planning system written in Access by a former employee back in 2013. The application ran on one specific computer in the workshop, because "that's the only one it would start on". Shift managers couldn't use it from their own laptops, planners had to walk to that one workstation, and twice a week the app would freeze and lose the last 20-30 minutes of work. After a 6-week project (~220 hours of work, roughly 65 000 zł) we rewrote it on .NET 8 with a SQL Server backend and a browser UI. After roll-out: access from any workstation in the company and from home, integration with Comarch Optima instead of retyping orders by hand, time to issue a shift production plan dropped from about 35 to 8 minutes. In the first three months the company recovered around 18 planner-hours a week.
When migration to SaaS makes sense
Typical case: your process doesn't differ much from the rest of the market, and someone already built a ready product for it — often better than what a small bespoke vendor would deliver. CRM, helpdesk, basic WMS for e-commerce, simple project management. Building your own software here is usually whittling at something that an off-the-shelf competitor will leapfrog in a month.
Migration makes sense when:
- You do the same thing a thousand other companies in your industry do — settling expenses, tracking leave, issuing simple service quotes.
- An off-the-shelf product covers 85% of your process and you are willing to adapt the missing 15% to the tool, not the other way round.
- Your teams are small (up to 30 people), so SaaS licence costs are meaningfully smaller than the cost of maintaining your own code.
- Regular feature growth (which the vendor ships monthly) matters more to you than total control.
Remember: SaaS migration isn't "free" just because you're not writing code. The cost is a data migration project, process mapping, training, and — always — several things you'll need to rethink differently from how they used to be.
How to take a bite out of this without drowning
Whichever path you pick, the most common Polish SME mistake is turning modernisation into "one big yearly project". That's the surest way for everyone to forget what we started for after six months.
What works instead:
- Start from one specific pain. Not "we're rewriting the whole app", but "in 6 weeks planners will issue the shift plan from home". The rest can wait.
- Cut it into 4-6 week chunks, each one delivering one usable thing. The worst project is one that hasn't produced anything in 4 months.
- The old and new app must run side by side for a few weeks. A "big bang" cutover on Friday evening almost never works in an SME — there are too few hands to fight Monday's fires.
- Migrate historical data deliberately. Not all of it. Pick what you really need operationally (usually the last 2-3 years), and leave the rest read-only in the old system.
What next
If there's an app in your company whose name you don't say out loud out of fear — that's a fair sign it's time to look at it. The "maintain, rewrite or migrate" decision isn't taken on slides. It's taken after an hour-long conversation in which someone outside the company looks at the process and tells you straight where sensible ends and sentiment about ten-year-old code begins.
We do those conversations regularly for Polish SMEs. The first one is free and takes half an hour.
An old app you're not allowed to touch isn't a competitive advantage. It's debt whose interest grows every quarter.