It's Just a Simple Rewrite — A Story of Estimates, Egos, and Eventual Success

When “We Just Need to Translate It” Meets Reality

The Company That Time Built

Hartmann & Söhne started in 1998 as a classic German Systemhaus — a software house serving a specific industry vertical. Their niche: configuration and order management for specialized industrial machinery. When a manufacturer needed to quote a complex custom machine with hundreds of configurable options, pricing rules, and engineering constraints, Hartmann’s software handled it.

The application, called MaschinenKonfigurator, became the standard in its market. Built in Borland Delphi with a local SQL Server database, it ran on customer premises. The software accumulated two decades of domain expertise: complex pricing algorithms, regulatory compliance rules for different export markets, integration with CAD systems, and the peculiar logic of industrial machinery configuration.

Klaus Hartmann, the founder’s son and now managing director, faced an uncomfortable reality in 2024. The Delphi ecosystem had contracted. Finding developers who understood Object Pascal was increasingly difficult. Their best developer, who had been with the company since 2003, was approaching retirement. Customers were asking about cloud access, multi-location deployment, and integration with modern ERP systems.

The decision seemed obvious: rebuild as a modern SaaS application. What followed proved far more complex than anyone imagined.

The Initial Enthusiasm

The leadership team gathered for what Klaus called a “transformation kickoff.” They had already made key technology decisions: Java with Spring Boot for the backend, a modern JavaScript framework for the frontend, PostgreSQL for the database, Kubernetes on AWS for hosting.

“We know exactly what the software needs to do,” Klaus said. “We have twenty years of working code. We just need to translate it to modern technology.”

Thomas, the head of development, nodded cautiously. “The business logic is all there. We documented most of it over the years.”

Maria, the product manager who had joined from a larger software company three months earlier, raised her hand. “How long did it take to build the original system?”

Thomas calculated. “The first version shipped after eighteen months. But we’ve been adding features continuously for twenty years.”

“So we’re not really rebuilding eighteen months of work,” Maria observed. “We’re rebuilding twenty years of accumulated capability.”

The room went quiet. Klaus looked at Thomas, who avoided his eyes. In the corner, Heike — the senior Delphi developer who had been with the company since 2003 — crossed her arms and said nothing. She had seen rewrites proposed before. None had happened. This time felt different — and not in a good way.

The Estimation Trap

The first planning sessions revealed a familiar pattern. The development team, now augmented with contractors experienced in Java and Spring Boot, began estimating the rewrite.

“User authentication and authorization — two weeks.”

“Basic configuration engine — three months.”

“Pricing rules — six weeks.”

“CAD integration — four weeks.”

The estimates accumulated into a comfortable eighteen-month timeline. Klaus approved the budget. The team began work with confidence.

Three months later, the authentication system was complete. The basic configuration engine existed but couldn’t handle the edge cases that made MaschinenKonfigurator valuable. The pricing rules, supposedly a six-week effort, had consumed two months and covered perhaps thirty percent of the actual complexity.

Thomas called an emergency meeting. “We’re not translating code. We’re rediscovering why the code was written that way in the first place.”

Martin, one of the Java contractors, pushed back. “Maybe if the original developers had documented their work properly, we wouldn’t be guessing.”

The room temperature dropped. Heike, who had been quietly reviewing a printout, looked up. “We documented everything that seemed important at the time. Twenty years of everything is a lot of documentation. Would you like me to show you where it is, or would you prefer to keep complaining?”

Klaus intervened before the situation escalated further. But the damage was visible. The new developers saw the legacy team as obstacles. The legacy team saw the new developers as arrogant newcomers who didn’t understand what they were dismantling.

The Knowledge Problem

The Delphi codebase contained twenty years of decisions. Some were documented. Most lived only in the code itself — or in the memories of developers who had moved on.

Heike became the project’s most valuable resource — though it took weeks for the new team to recognize it. She could look at a block of Object Pascal and explain: “This handles the case when a customer configures a machine for the Japanese market but wants German safety certifications for re-export. We added it in 2011 after losing a major order.”

The new Java developers would implement a feature, demonstrate it to Heike, and watch her shake her head. “That works for standard configurations. But what about combination constraints? What about legacy pricing agreements? What about the machines configured before we changed the component numbering scheme in 2015?”

Each “simple” feature had tentacles reaching into edge cases that only became visible when someone tried to use the system the way real customers did.

The Pivot: Running in Parallel

Six months into the project, Klaus faced a difficult decision. The new system had consumed half the budget but delivered perhaps twenty percent of the required functionality. Continuing the same approach meant either dramatically increasing the budget or delivering a system that couldn’t replace the original.

Maria proposed a different strategy. “What if we don’t try to replace MaschinenKonfigurator all at once? What if we run both systems in parallel and migrate capability by capability?”

The approach had trade-offs. Running two systems increased operational complexity. Customers would need to work with both during the transition. But it offered something the original plan lacked: the ability to learn and adjust without betting everything on a single outcome.

The team restructured the project around three principles:

Capability migration, not code translation. Instead of translating Delphi modules to Java, they identified discrete capabilities customers actually used. Each capability became a self-contained piece of the new system.

Production validation at every step. Each capability went to production as soon as it was ready, running alongside the legacy system. Customers could choose which system to use for that function.

Continuous learning loops. Every capability deployment included telemetry. Usage patterns, errors, and performance metrics guided prioritization.

The First Real Victory

The team chose pricing calculations as their first target. Pricing was complex but relatively self-contained — it consumed configuration data and produced quotes without deep integration into other parts of the system.

Building the pricing engine took three months, not six weeks. But this time, the team had Heike reviewing every algorithm, comparing outputs against the Delphi system, and identifying edge cases before customers encountered them.

The new pricing engine launched as an optional feature. Customers could generate quotes using either system. Telemetry tracked accuracy — did the new engine produce the same results as the old one?

The first week revealed three edge cases the team had missed. By the second week, those were fixed. By the fourth week, most customers had switched to the new engine permanently. It was faster, accessible from any browser, and produced identical results.

More importantly, the team had learned something: the new system didn’t need to replicate every feature of the old one. It needed to replicate the capabilities customers actually used.

The Configuration Engine Challenge

Pricing was the warmup. The configuration engine — the heart of MaschinenKonfigurator — presented a different magnitude of challenge.

The Delphi configuration engine encoded rules that had evolved over twenty years. Which components were compatible with which bases. What regulatory requirements applied in different markets. How customer-specific pricing agreements modified standard rules. The dependencies formed a web that no single person fully understood.

Thomas proposed an unconventional approach: “We’re not going to rebuild the configuration engine. We’re going to build a new one that learns from the old one.”

The team built the new configuration engine with explicit rule definitions — clear, testable, documented. But every configuration the new engine produced was also run through the legacy Delphi system. Discrepancies triggered investigations.

This “shadow mode” approach served multiple purposes. It validated correctness. It exposed undocumented rules when the systems disagreed. And it built confidence among the team that the new system actually worked.

The configuration engine took eight months instead of the originally estimated three. But when it launched, it launched with confidence.

The Human Dimension

Technical challenges weren’t the only obstacles. The transformation strained the organization in ways Klaus hadn’t anticipated — and nearly broke it.

The first major crisis came three months after the pivot to parallel running. Jürgen, a Delphi developer who had been with the company for twelve years, requested a private meeting with Klaus.

“I can’t do this anymore,” Jürgen said. His voice was steady, but Klaus noticed his hands were shaking. “Every day I come in and watch contractors tear apart code I spent years building. They don’t ask why things work the way they do. They just rewrite it and then blame us when it breaks.”

“We need you, Jürgen. You know the pricing module better than anyone.”

“That’s the problem.” Jürgen’s composure cracked slightly. “I’m not a resource to be mined. I’m a person. And I’m tired of being treated like a museum exhibit everyone needs to visit before they can do their real work.”

Klaus promised changes. Jürgen agreed to stay — for now.

Two weeks later, Martin, one of the Java contractors, pushed too far. In a team meeting, he openly mocked a section of Delphi code displayed on screen. “Who wrote this spaghetti? This is why legacy systems need to die.”

Jürgen had written that code. He stood up slowly, face pale. “I wrote it. In 2014. When we had three days to fix a critical bug for our largest customer. It’s not elegant, but it’s worked for ten years without a single failure.” His voice broke on the last words. He left the room.

The silence that followed was devastating. Lisa, a junior developer who had been taking notes, started crying. She wasn’t sure why — the accumulated tension had simply become too much.

Klaus found Jürgen in the parking lot, sitting in his car. He wasn’t coming back inside.

“I’m done,” Jürgen said. “I’ll work out my notice period, but I’m not attending any more meetings with those people.”

No amount of persuasion changed his mind. Jürgen left four weeks later, taking with him irreplaceable knowledge of the pricing engine’s most complex algorithms. The team spent the next two months reverse-engineering code he could have explained in an afternoon.

As for Martin — Klaus fired him the next day.

“You can’t fire me for having an opinion,” Martin protested.

“I’m firing you for creating a hostile environment that cost us a twelve-year employee,” Klaus replied. “Your opinion destroyed more value in five seconds than you created in five months. Clear your desk.”

Martin threatened legal action. Nothing came of it. But word spread quickly among the remaining contractors: the old rules had changed.

Meanwhile, Heike had stopped coming to the integration meetings. When Klaus asked why, she was blunt: “Every time I explain something, someone rolls their eyes. I’ve been protecting this system for twenty years. If they don’t want my help, I’ll wait until they ask.”

Klaus saw a people problem. And like many executives facing people problems, he reached for a familiar solution: outside help.

The Consultants

The management consulting firm came highly recommended. They specialized in “organizational transformation” and “change management.” Their lead consultant, Dr. Berger, arrived with a team of three junior analysts and a methodology called “Adaptive Transition Framework.”

“Technical projects fail because of people, not technology,” Dr. Berger explained in his initial presentation. “We’ll align your stakeholders, establish clear communication protocols, and create accountability structures that drive results.”

Thomas was skeptical. “Have any of your team actually built software?”

Dr. Berger smiled patiently. “We don’t need to understand the technical details. Human dynamics are universal. Resistance to change follows predictable patterns regardless of industry.”

For six weeks, the consulting team conducted interviews, facilitated workshops, and produced a 47-page report. They identified “communication gaps,” “unclear role definitions,” and “insufficient change readiness.” Their recommendations included a new governance structure, weekly alignment meetings, and a “transformation champion” role.

The weekly alignment meetings added three hours to everyone’s schedule. The governance structure created approval bottlenecks that slowed decisions. The transformation champion — a junior manager from sales — had no idea what the developers were talking about and quietly stopped attending after two weeks.

Heike attended one of Dr. Berger’s “legacy stakeholder integration sessions.” She walked out after twenty minutes. When Klaus asked what happened, she said: “He asked me to describe my ‘emotional relationship’ with the codebase. I told him my relationship with the codebase is that I know how it works and they don’t. He said I was exhibiting ‘defensive posturing typical of change-resistant personas.’”

That evening, Heike sent Klaus an email with her resignation letter attached. “I’ve given this company twenty years,” she wrote. “I won’t spend my final working years being psychoanalyzed by people who couldn’t compile Hello World.”

Klaus called her immediately. It took forty-five minutes to convince her to delay submitting the resignation. “Give me one week,” he said. “If nothing changes, I’ll accept it without argument.”

Thomas was more direct in the next leadership meeting. “Klaus, these consultants are burning €15,000 a week and making everything worse. The developers who were starting to work together are now sitting in meetings drawing stakeholder maps. Meanwhile, no code is getting written. And we nearly lost Heike last night — the one person who can actually finish this project.”

Dr. Berger defended his approach. “Transformation is uncomfortable. Resistance indicates we’re addressing the real issues.”

“Resistance indicates that people who build software don’t enjoy being psychoanalyzed by people who’ve never built software,” Thomas replied.

The breaking point came when the consultants recommended “temporary role rotation” to build empathy — suggesting that Heike spend two weeks working with the Java team while a Java developer “shadowed” her Delphi work.

Heike’s response was icy. “You want someone who doesn’t know Object Pascal to shadow twenty years of work they can’t read? And you want me to write Java, which I’ve never used, while the project burns? This isn’t a team-building exercise. This is a company that’s about to lose its only product.”

Klaus finally saw what Thomas and Heike had been telling him for weeks. The consultants understood generic organizational dynamics, but they had no grasp of what software development actually required. Their frameworks treated all resistance as emotional — never considering that some resistance might be rational disagreement from people who understood the problem better than the consultants did.

He ended the engagement. €90,000 spent, six weeks lost, and the team more fractured than before.

Klaus realized he had been looking for an external solution to an internal problem. The friction wasn’t about “change readiness” or “stakeholder alignment.” It was about respect — and respect couldn’t be workshopped into existence.

He called a meeting — not about code, but about culture. No consultants. No frameworks. Just honesty. “Heike isn’t here to hand off knowledge and leave. She’s here to help us build something better than what we had. When the new system is done, she’ll have shaped it. Anyone who can’t work with that should tell me now.”

The room was silent.

“And Heike — I need you in every integration meeting. Not as someone being interrogated, but as the technical authority on what this system actually does. If someone rolls their eyes, I want to know about it.”

Heike nodded slowly. It was the first time Klaus had publicly acknowledged her role as essential rather than transitional.

The team restructured. Heike became a technical advisor who reviewed designs before implementation. Legacy developers paired with new developers, each teaching the other. Two more contractors left — they wanted greenfield work, not archaeological expeditions. But the ones who stayed began to understand: the goal wasn’t “replace the old system.” It was “build the next generation of what we started.”

The Multi-Tenant Challenge

Running on customer premises meant MaschinenKonfigurator never needed true multi-tenancy. Each installation was isolated. Customer data couldn’t leak between installations because there was nothing to leak into.

SaaS changed everything. Multiple customers would share infrastructure. Their configurations, pricing, and business rules needed complete isolation while running on shared systems.

“This isn’t a feature,” Maria observed. “This is a fundamental architectural decision that affects everything.”

The team had already built several capabilities assuming single-tenant operation. Retrofitting multi-tenancy would require significant rework.

Thomas made the call: “We stop feature development for six weeks. We rebuild the foundation for multi-tenancy before going further.”

Klaus pushed back hard. “Six weeks of no visible progress? The board is already asking questions. I’ve told them we’re on track.”

“Then tell them we’re not on track,” Thomas replied. “Because if we keep building on this foundation, we’ll be explaining in twelve months why we need to start over. Again.”

The argument continued for an hour. Maria finally broke the deadlock: “Klaus, which conversation do you want to have with the board — ‘we paused for eight weeks to fix architecture’ or ‘we spent eighteen months building something we have to throw away’?”

Klaus authorized the pause. It was the hardest decision he’d made since starting the project.

The multi-tenancy retrofit took eight weeks, not six. It touched every capability already built.

The rework nearly broke what remained of team morale. Andreas, a senior Java developer who had joined full-time after the contractor exodus, confronted Thomas in the hallway. “You’re telling me the last four months of my work is being thrown away?”

“Refactored, not thrown away.”

“That’s corporate speak for thrown away.” Andreas was visibly shaking. “I moved my family here for this job. I left a stable position in Munich. And now you’re saying my work doesn’t count?”

Thomas spent an hour talking Andreas down. Two other developers had similar reactions — one threatened to quit on the spot, the other stopped speaking to Thomas entirely for a week. The tension was so severe that Maria started holding private one-on-one meetings just to let people vent without fear of being overheard.

Thomas spent hours in those weeks explaining that the original design wasn’t wrong, just incomplete for requirements that had become clear later. Some developers accepted this. Others never fully trusted management again.

When the retrofit was done, the system could scale to hundreds of tenants without architectural changes. More importantly, the team had survived a genuine crisis together. But the scars remained. Trust, once broken, rebuilds slowly if at all.

Finding the Right Deployment Rhythm

Early in the project, deployments were major events. The team would accumulate changes for weeks, then deploy in a carefully orchestrated release. Each deployment was stressful — so much had changed that failures were unpredictable.

The infrastructure team, led by a DevOps engineer named Felix, invested heavily in deployment automation. Kubernetes orchestration. Automated testing pipelines. Feature toggles that allowed code to be deployed without being activated.

Gradually, deployment frequency increased. Weekly became daily. Daily became multiple times per day. Each deployment was smaller, lower risk, easier to troubleshoot if something went wrong.

The psychological shift was profound. Developers stopped thinking in terms of releases and started thinking in terms of continuous improvement. A bug fix could reach production in hours. A new capability could launch incrementally, enabled for a few customers before rolling out broadly.

The Sunset Conversation

Eighteen months after the project began — the original timeline for complete replacement — about sixty percent of MaschinenKonfigurator’s capability existed in the new SaaS platform. But that sixty percent covered perhaps ninety percent of daily customer usage.

Klaus faced a choice: continue running both systems indefinitely, or begin sunsetting the legacy application.

“Some customers will resist,” warned the sales director, Stefan. “Müller Maschinenbau has been with us for fifteen years. They’ve already complained about the new interface three times.”

“Some capabilities we’ve never rebuilt will disappear,” warned Thomas. “There are features in the Delphi system that two customers use. Are we keeping the whole legacy system running for two customers?”

Heike spoke up — something she did more often now. “Those two customers pay us €180,000 a year combined. One of them is the reference customer we use in every sales presentation. If we tell them their workflow is being retired, we might lose them.”

The room divided. Sales wanted to keep every customer happy. Development wanted to stop maintaining two systems. Finance pointed out that running parallel infrastructure was costing €8,000 per month.

The team analyzed usage telemetry extensively. They identified capabilities that genuinely mattered versus those that existed only because no one had removed them. They talked to every customer about their actual needs versus their theoretical preferences.

Klaus made the call. “We rebuild the workflow for Müller Maschinenbau. It’s three weeks of work, and it keeps our best reference customer. The other legacy features get documented alternatives and twelve months notice.”

Stefan from sales wasn’t satisfied. “What do I tell customers who complain?”

“Tell them the truth,” Klaus said. “We’re building something better. Some things won’t make the transition. We’ll help them adapt.”

The sunset plan gave customers twelve months of parallel operation. Three customers chose not to migrate and eventually left. Two of them had been paying minimal fees and consuming disproportionate support resources. The third, a mid-sized manufacturer, moved to a competitor — a loss that stung but validated that the company couldn’t be everything to everyone.

The Final State

Two and a half years after the transformation began, Hartmann & Söhne had completed their journey. The new platform — renamed MachineConfigure to signal the transition — served all existing customers plus new ones who would never have considered the legacy desktop application.

The results exceeded expectations in some areas and fell short in others:

Performance: The new system handled complex configurations in seconds instead of minutes. Customers repeatedly cited this as the most visible improvement.

Accessibility: Multi-location teams could now collaborate on configurations. Mobile access enabled sales representatives to create quotes on-site with customers.

Integration: Modern APIs enabled connections to ERP systems, CAD platforms, and e-commerce channels that were impossible with the legacy architecture.

Feature parity: About eighty-five percent of legacy features made the transition. The remaining fifteen percent were either rebuilt with different approaches or retired entirely.

Timeline: Two and a half years instead of eighteen months. The project took longer than the optimistic original estimate but significantly less time than a full parallel development approach would have required.

Cost: Roughly double the original budget — including €90,000 on management consultants who made things worse, months of lost productivity from the knowledge gap when Jürgen left, and the cost of firing Martin before Klaus accepted that respect can’t be workshopped and toxicity can’t be tolerated. Expensive, but the alternative — continuing to maintain an increasingly unsupportable legacy system — would have cost more over time.

Lessons From the Journey

Klaus, reflecting on the transformation a year after completion, identified principles that might help other organizations facing similar challenges:

The knowledge is in the people, not the code. Retaining and respecting the developers who built the legacy system proved more valuable than any documentation. Heike caught problems that no automated testing could find — but only after the team learned to listen to her. Jürgen’s departure over a contractor’s thoughtless mockery cost months of reverse-engineering time. The contractors who dismissed the legacy team’s knowledge were the first to leave — or be shown the door. The ones who stayed learned humility.

Generic management consulting rarely helps technical transformations. The consultants who recommended “stakeholder alignment workshops” and “change readiness assessments” had never shipped software. They treated rational technical disagreement as emotional resistance. The €90,000 spent on frameworks and governance structures was €90,000 not spent on solving actual problems. When your experts tell you something won’t work, consider that they might be right.

Parallel running reduces risk dramatically. Running both systems simultaneously allowed learning and adjustment. The ability to compare outputs built confidence that the new system actually worked correctly.

Small, frequent deployments change everything. Moving from big-bang releases to continuous deployment transformed the team’s relationship with risk. Small changes were easier to validate and easier to roll back.

Multi-tenancy isn’t a feature — it’s a foundation. Trying to retrofit multi-tenancy after building single-tenant capabilities wasted months. Architectural decisions need to be made early, even when features seem more urgent.

Not every feature deserves survival. Legacy systems accumulate capabilities that outlive their usefulness. Transformation is an opportunity to prune, not just port.

The original timeline is always wrong. Not because the team can’t estimate, but because the team can’t know what they don’t know. Building in substantial contingency isn’t pessimism — it’s realism.

The Story Continues

Hartmann & Söhne’s transformation wasn’t an ending. It was a transition to a new way of operating. The SaaS model brought new challenges: monitoring uptime across multiple customers, managing subscription billing, handling data residency requirements for international clients.

But the organization had also built new capabilities. They could deploy improvements daily instead of annually. They could observe how customers actually used the system, not just how customers described their usage. They could experiment with features before committing to them fully.

The specialized machinery market still needed sophisticated configuration tools. Hartmann & Söhne still provided them. The technology had changed completely. The value proposition remained the same.

Heike retired six months after the new platform launched — on her own terms, having shaped the system that would carry her work forward. At her farewell party, she told Klaus: “I was ready to quit when Martin called my documentation useless. I’m glad I stayed.”

“So am I,” Klaus replied. “We couldn’t have done it without you.”

“No,” she agreed. “You couldn’t have. Remember that next time someone tells you a rewrite is simple.”

---

This is a work of fiction. Any resemblance to actual companies, events, or persons is entirely coincidental. However, if you recognized your own organization in this story, that’s probably not a coincidence — it’s a pattern.