Software analysis in a takeover, also called software quality analysis, is a structured way to assess the condition of an unfamiliar code base within a short time. Static analysis tools such as SonarQube give a first read on maintainability, robustness and security, even when no running system is available. Missing documentation and components that are handed over incomplete are among the most common risks in these takeovers.
Key Takeaways
- Cutting testing first when the budget gets tight makes a project more complicated and more expensive, not cheaper, because skipping quality assurance only postpones problems.
- A full-time test manager on a development team is unusual, but brings a structure that takes pressure off every other discipline.
- Be open about project risks early: bad news you hold back comes back at a worse moment.
- In practice, an agile mindset means rebuilding the team mid-project when the requirements shift, for example by bringing in a second architect in place of developers.
- A zero-downtime migration is far more reliable when it is fully rehearsed with real production data three weeks ahead.
Taking Over Third-Party Software Means Expecting Surprises
When you buy existing software, software analysis is often the only way to find out what you are actually getting. You rarely inherit a cleanly documented package. More often it is a grab bag: you don’t know exactly what’s inside, what shape the quality is in, or whether the system can be maintained at all.
That was the situation a public transport provider faced when it took over an existing ticket shop. The deal covered the whole product, not just the right to use it. Before the purchase, nobody knew which components would come with it, how good the code was, or whether the takeover would pay off.
Sonja Trimmel and Helmut Nitsch worked on this project. Their experience shows what matters when you take over an unfamiliar code base and bring it into a state you can build on.
How Static Software Analysis Evaluates an Unfamiliar Code Base
Even under time pressure you can get a first assessment, as long as you use static analysis. The team had a day and a half for the initial evaluation. With several thousand lines of code, that is not enough for a complete manual review.
Static analysis tools such as SonarQube give a useful picture in this situation. They report on maintainability, robustness and security without needing a running system.
For a ticket shop, security deserves a close look. A system like this is highly exposed to the outside world and handles a lot of traffic. Both are properties that automated analysis covers well.
In this case there was no running system to test. The ticket shop was visible online, and the team examined only part of the code it had received, using static analysis and a manual read-through. For a first estimate, that is enough to derive concrete recommendations.
The Code Wasn’t the Problem, the Missing Pieces Were
In a software takeover, the biggest obstacle is often not the code but everything that doesn’t come with it. The code the team reviewed was in good shape, with no serious defects.
The gaps around it were harder. Because responsibilities kept changing hands, some components arrived late. The documentation fell short of what a professional team would treat as standard.
The real sticking point surfaced during onboarding: part of the software existed only as a black box, compiled binaries with no source code. About two thirds of the software was available as source code, one third was not.
That is the moment a takeover you can plan turns into a grab bag. Suddenly the question is how to keep working when part of the source code is missing.
Why an Agile Mindset Matters When Taking Over Unknown Software
If you take over software you don’t know, you need to be able to change the plan along the way. The original idea was straightforward: analyze the code, refactor it, add a few features, fix bugs and bring the documentation up to date.
In reality the focus shifted. A lot of time went into analysis, because the team had to understand the whole system, track down every part and prepare it for further use. The plan to refactor turned into a different question: what does the customer really need first?
The team was rebuilt to match. Instead of carrying on with the original lineup, some developers were taken off the project and a second architect was brought in. In total the project had five months, two architects and two developers.
Helmut Nitsch stresses that this has nothing to do with agility as a label.
“I’m not talking about what gets preached to you. I mean having an agile mindset so you can react flexibly to certain things. That was vital.”
(Helmut Nitsch)
That flexibility, together with the trust the client extended up front, was a success factor for both sides.
How to Plan a Migration Without Downtime
A migration with no allowed downtime works when you rehearse it repeatedly with real data. A ticket shop cannot go offline, so the switch has to happen more or less instantly.
Three weeks before the go-live date, the team rehearsed the migration with the complete production data and had everything ready. A dry run like this exposes sources of error before they hit you for real.
The timing made it harder. After several delays, the migration fell in the vacation period, and the chief architect was away for the three critical weeks. A migration during a heatwave and in vacation season raises the risk of human error.
Preparation was the answer. The second architect and the lead developer rehearsed the migration and got everything ready. Once the chief architect was back, the whole team walked through it again together.
The date was no accident either. The team picked a Tuesday at noon, statistically the time with the fewest users in the ticket shop. The result: the actual cutover took five minutes, and then everything was running.
The Underrated Factors on Migration Day
Technology and planning are only part of it. The soft factors count too. On migration day, all the developers sat together in an air-conditioned room, started early and had food and drinks laid on.
Catering and morale are not side issues. A good working environment on the critical day lowers stress, and with it the chance of mistakes. The rule of thumb behind it is simple: plan twice, execute once.
Honesty and Communication Carry the Project
Once surprises show up, communication decides how things turn out. Four companies were involved in this project, so coordination had to be tight.
The team was consistent about it: every new finding went out to everyone involved right away. They got the team together, wrote down the possible scenarios (four or five in one case) and everyone added their assessment.
Decisions were forced deliberately. The rule in meetings was that nobody leaves the room until a decision is made, because delay only costs money. Hard prioritization is part of that.
The most critical phase came almost at the start. Missing documentation, code that hadn’t been delivered yet and the realization that time and budget wouldn’t stretch far enough created real pressure, all the more because other projects depended on this one.
In that situation, only openness helped. Rather than keep problems quiet, the team put the scenarios on the table: this approach gets you this far, that one gets you further, and only this one gets you all the way. Hiding information gets you nowhere. The problem you keep quiet about comes back later, usually at the worst possible moment.
Customer Commitment Is More Than Budget
A client shows real commitment when it makes sure the whole team speaks the same language. Before the project started, the client sent the entire team on a Scrum course.
The point was smooth collaboration, not knowledge transfer for its own sake. When everyone understands the same terms, coordination doesn’t lose time to friction.
The effect was noticeable. When the team said something, the other side knew exactly what was meant. That kind of engagement is very different from the familiar pattern where the customer says “just get on with it” and backs you up with a few part-timers.
When Budgets Shrink, Testing Goes First, and That Backfires
One thing hasn’t changed in more than twenty years of testing: when money gets tight, testing is the first thing cut. That doesn’t make a project cheaper. It makes it more complicated and more expensive.
Development is more than coding. A development team needs other disciplines as well, from requirements engineering to testing. Those disciplines return more than they cost and help get a project over the line.
This project had a full-time test manager, which is unusual in development projects. More often, someone tests on the side in a half-time role. Having a full-time test manager gave the whole approach a lot of structure.
Lessons for the Next Software Takeover
The most important lesson: build a diverse team from day one, even if you think you know how the project will go. In this project the team had to be reshuffled several times whenever the direction changed.
An interdisciplinary team can swap one skill for another when the project takes a turn. That ability to reshuffle was a success factor. The team covered app development, several cloud technologies and expertise in testing, project management and automation, all at a comparable level.
In practice, the key factors come down to this:
| Factor | Effect in the Project |
|---|---|
| Static analysis up front | Quick quality assessment even without a running system |
| Agile mindset | Adjust the plan and team setup along the way when new gaps appear |
| Rehearse the migration repeatedly | Find sources of error before go-live, five-minute cutover |
| Open communication | Put problems on the table early, force decisions |
| Customer commitment | A shared Scrum course reduces friction |
| Full-time testing | Clear structure instead of saving in the wrong place |
Taking over third-party software is always a risk. But if you combine analysis, flexibility, honest communication and a broadly skilled team, even a grab bag can become a product you can build on.
Frequently Asked Questions
What can static code analysis accomplish when no executable system is available?
It provides insights into maintainability, robustness, and security without requiring the software to run. In the ticket shop project described, only one and a half days were available for the initial assessment, not enough time for a full manual review of several thousand lines of code. Tools like SonarQube covered the provided portion of the code, supplemented by a manual review. That’s sufficient for an assessment with concrete recommendations.
What risks are associated with purchasing existing software?
It’s usually not the code itself that’s the biggest hurdle, but rather what’s missing. In the case described, the code that was reviewed was well-written, with no serious defects. The problems lay in the gaps around it: documentation below professional standards, components that were delivered late due to shifting responsibilities, and one-third of the software that was available only as a compiled version without source code.
What are the benefits of testing a migration in advance with real live data?
The dry run uncovers sources of error before they strike in a real-world scenario. Three weeks before the deadline, the migration was fully tested and prepared using all live data. The actual cutover then took five minutes, after which the system was up and running. The rule of thumb behind this is: plan twice, execute once. For a store with zero tolerance for downtime, this is the decisive factor.
Does the chosen timing affect the risk of a migration?
Yes, and measurably so. A Tuesday at noon was chosen for the ticket shop’s cutover: statistically the time with the fewest users. Heat and the vacation season compounded the challenge, as did the chief architect’s absence during the three weeks leading up to it. This was offset by having the second architect and the lead developer run through the process, and then going over everything together again after the lead architect’s return.
Why does the plan almost inevitably change during a software takeover?
Because the analysis takes up more time than expected. The plan had been to perform code analysis, refactoring, implement a few features, fix bugs, and create documentation. In reality, a lot of time went into fully understanding the system and identifying all its components. This led to the question of what the customer really needed in the first phase. The team setup was reorganized: some developers were removed, and a second architect was added.
Is it worth cutting back on testing first when the budget is tight?
No. That doesn’t make a project cheaper; it makes it more complicated and more expensive, because skipping quality assurance only delays problems. A development team needs more than just coding (from requirements engineering to testing), and these disciplines deliver more value than they cost. In the project described, a full-time test manager was on staff instead of the more common part-time role. This provided a strong structural framework for the process.
How do you handle bad news when multiple companies are involved in a project?
Every new finding must be shared immediately with all stakeholders. With four companies involved, the team was convened, scenarios were written down (in one case, four or five), and everyone contributed their assessment. In meetings, the rule was not to leave the room without reaching a decision. Hiding information accomplishes nothing: the problem that was kept secret will surface later, usually at the worst possible moment.
How should a team be structured for the adoption of third-party software?
Diverse from the very beginning, even if the project’s course seems clear. An interdisciplinary team can replace one area of expertise with another as soon as the direction changes. In the case described, app development, various cloud technologies, and expertise in testing, project management, and automation were all present at a comparable level. It was precisely this ability to pivot in the middle of the project that was one of the key factors in its success.
