Technology Due Diligence: What to Check Before Making a Major Technology Investment

Technology Due Diligence Can Stop an Expensive Decision Becoming an Expensive Problem

Technology due diligence gives you a clearer picture of what you are actually committing to before you make a major technology investment.

A proposal can look convincing. The demonstrations work. The supplier sounds confident. The projected savings stack up nicely in a spreadsheet. But what happens if the technology is difficult to maintain, depends heavily on one person, has hidden security risks or will cost far more to operate than expected?

A good technology due diligence review looks beyond the sales presentation. It examines whether the technology, people, costs, risks and delivery approach support the business outcome you are expecting.

I have spent more than 35 years working with technology from both sides of this equation. One lesson has remained remarkably consistent: technology decisions rarely fail because somebody chose the wrong programming language. Problems usually appear where business expectations, people, delivery and technology don’t line up.

Takeaways

What Is Technology Due Diligence?

Technology due diligence is an independent assessment of a proposed technology investment to understand its benefits, costs, risks, dependencies and ability to support the business.

The exact scope depends on what you are considering.

You might be:

• investing hundreds of thousands of dollars in a new business platform
• commissioning custom software
• replacing an important operational system
• buying a software product or technology-enabled business
• making a substantial investment in AI or automation
• entering a long-term agreement with a technology supplier
• acquiring technology or intellectual property as part of a business transaction

The purpose isn’t to find reasons to say no.

It is to make sure you understand what you are saying yes to.

That distinction matters. An effective review gives decision-makers better information. Sometimes it uncovers a serious problem. Sometimes it confirms that the proposed investment is sensible. Quite often, it identifies changes that make a good investment safer.

That’s why I see Technology Due Diligence as a business decision-making exercise rather than simply a technical review.

When Should You Conduct Technology Due Diligence?

The best time is before you become heavily committed.

That sounds obvious, yet I regularly see businesses ask for an independent review after contracts have been signed, money has been spent and delivery has started going wrong.

You have much more freedom before that point.

Technology due diligence makes sense when the size, complexity or business impact of an investment means getting the decision wrong would hurt.

A $50-a-month software subscription probably doesn’t need an independent review. A $500,000 platform implementation probably deserves more scrutiny.

The same principle applies where the investment itself isn’t huge but the business dependency is.

Imagine a $50,000 system becoming responsible for every customer booking, payment or order. Its purchase price may be modest, but its importance to the business is enormous.

I normally look at four factors:

1. Cost: How much are you committing?
2. Dependency: How important will this technology become?
3. Complexity: How difficult will it be to implement, operate or replace?
4. Risk: What happens to the business if it doesn’t work as expected?

The higher those factors become, the stronger the case for independent technology due diligence.

1. Start With the Business Case, Not the Technology

Before examining architecture, security or software, I want to know why the business is considering the investment.

What problem are you trying to solve?

This is where surprisingly large investments can start to wobble.

A business may say it needs a new system because the current one is old. That isn’t yet a business case. What is the old system preventing the business from doing?

Perhaps customer onboarding takes too long. Staff are manually copying information between systems. Reporting takes days. Growth requires hiring more administration staff. Customers are complaining.

Those are business problems.

Now we have something against which the proposed technology can be assessed.

Ask:

• What problem are we solving?
• What measurable outcome do we expect?
• Who benefits from the change?
• What happens if we do nothing?
• What alternatives have been considered?
• How will we know the investment has succeeded?

This reflects my broader approach to Technology Strategy. Technology should support the business, rather than the business being forced to accommodate technology for its own sake.

2. Check Whether the Proposed Technology Actually Fits

A technically impressive product can still be the wrong product.

One common mistake is evaluating software by the number of features it has. The better question is whether it supports the processes that matter to your organisation.

Suppose you run an engineering company considering a new project management platform. It might have 200 features. If it cannot handle the way your engineers approve variations, allocate resources or report project costs, those extra features aren’t much consolation.

Look at the important workflows.

Ask the supplier to demonstrate your scenarios rather than their standard demonstration.

For example:

“Show me how one of our project managers would create a variation, obtain approval and have that change reflected in the project budget.”

That is much more useful than watching a polished generic presentation.

Also talk to the people who will actually use the system.

This is where people before technology becomes very practical. A platform that looks perfect to senior management but makes everyday work harder for 80 employees may create a very different return on investment from the one in the business case.

3. Understand the Real Cost of the Technology Investment

The quoted price isn’t necessarily the cost.

A proper technology investment assessment should consider the total cost of ownership.

That may include:

Cost	What to Check
Purchase or subscription	Initial and recurring charges
Implementation	Configuration, consulting and project costs
Integration	Connecting existing systems
Data migration	Cleaning, converting and moving data
Internal staff	Time taken away from normal work
Training	Initial and ongoing training
Infrastructure	Cloud, hosting, networks or devices
Support	Support plans and internal support effort
Licensing	Users, modules, APIs and third-party software
Upgrades	Future versions and mandatory changes
Exit costs	Data extraction, migration and replacement

This can materially change the investment case.

A platform quoted at $150,000 may require another $100,000 of implementation, integration and internal effort before it delivers value.

You should also understand how costs change as you grow.

What happens when you move from 50 users to 150? What happens if transaction volumes double? Are integrations charged separately? Does data storage become expensive?

The right question isn’t simply, “What does it cost?“

Ask, “What is this likely to cost us over three to five years?“

4. Review Architecture, Integration and Technical Debt

You don’t need to be a software engineer to understand the business implications of technical architecture.

You do need someone asking the right questions.

If you are acquiring or commissioning software, look at how it has been designed and maintained.

Important questions include:

• Is the technology current and supported?
• Are important components approaching end of life?
• Can the system handle expected growth?
• How difficult is it to change?
• How well documented is it?
• What other systems does it depend on?
• Are integrations reliable and maintainable?
• Is there substantial technical debt?

Technical debt is the accumulated cost of shortcuts, outdated technology and design decisions that make future changes harder or more expensive.

Technical debt isn’t automatically bad.

Every established software product has some. The question is whether it is understood, managed and proportionate.

I become more concerned when nobody can explain where the technical debt is or when every seemingly simple change requires weeks of work.

That often tells you more than a glossy architecture diagram.

5. Assess Cybersecurity, Privacy and Data Risk

Cybersecurity deserves specific attention because a new technology investment can introduce new access to systems, customer information and commercially sensitive data.

NIST describes due diligence as researching relevant information about suppliers or products so informed acquisition decisions can be made. Its cybersecurity supply-chain guidance also highlights areas including resilience, foundational cyber practices and supply-chain dependencies.

Your assessment should consider:

• what data the technology stores
• where that data is stored
• who can access it
• how users are authenticated
• how privileged access is controlled
• how vulnerabilities are managed
• whether data is encrypted appropriately
• backup and recovery arrangements
• incident response procedures
• third-party dependencies
• relevant privacy or regulatory requirements

For Australian organisations, the ASD Essential Eight provides useful guidance on practical cyber controls. The NIST Cybersecurity Framework is another useful reference for managing cybersecurity risk.

Certifications can provide useful evidence, but don’t let them replace questions.

A supplier saying “we’re ISO 27001 certified” doesn’t tell you everything about the specific system you are buying, how it will be configured or how your data will be handled.

6. Look for Key-Person Dependency

One of the biggest technology risks may be a person rather than a platform.

Ask a simple question:

Who understands how this actually works?

If the answer is one developer, one contractor or the founder, investigate further.

Key-person dependency becomes particularly important when buying software, acquiring a technology company or investing in custom development.

Look at:

• documentation
• source-code ownership and access
• deployment knowledge
• infrastructure access
• administrator accounts
• support knowledge
• architecture knowledge
• relationships with critical suppliers

Then ask what would happen if that person disappeared tomorrow.

Could another capable person operate the system?

Could they deploy a release?

Could they recover it after an outage?

Could they understand why important decisions were made?

This doesn’t mean the key person is doing anything wrong. In smaller organisations, concentrated knowledge develops naturally.

The risk appears when the business doesn’t recognise or manage the dependency.

This is also why Technology Leadership matters. Good technology leadership builds organisational capability rather than allowing critical knowledge to remain locked inside individual heads.

7. Examine the Supplier and Third-Party Dependencies

You aren’t only investing in technology. You may be investing in a chain of companies and services that keep it running.

Identify the important dependencies.

These might include cloud hosting, payment gateways, identity providers, data suppliers, AI models, messaging services, software libraries and external APIs.

Then ask:

• What happens if one disappears?
• Can it be replaced?
• How difficult would replacement be?
• Who owns the supplier relationship?
• Are contracts transferable?
• Are there minimum commitments?
• Could prices increase sharply?
• Are there restrictions on how data can be used?
• Is the business locked into a particular vendor?

Vendor dependency isn’t automatically a problem.

Using established services such as AWS, Microsoft Azure or Google Cloud may make much more sense than building equivalent infrastructure yourself.

The issue is unmanaged dependency.

You need to know where those dependencies exist and what they mean for your investment.

8. Check Ownership and Intellectual Property

This area is easy to overlook until it becomes painfully important.

If you are paying for custom software, buying a product or acquiring a business, establish who owns the intellectual property.

Don’t assume that paying for development automatically means you own everything.

Check:

• source-code ownership
• contractor agreements
• employee intellectual-property clauses
• third-party components
• open-source software
• commercial libraries
• design assets
• domains
• cloud accounts
• repositories
• licences

Legal ownership questions should be reviewed by an appropriate lawyer. The technology due diligence process helps identify what needs legal verification.

The practical test is simple.

Can the organisation prove that it owns or has the right to use everything required to operate the technology?

If the answer isn’t clear, keep digging.

9. Review Delivery Capability, Not Just the Product

A working product today doesn’t tell you whether the team can continue improving it tomorrow.

This matters particularly when investing in a software company or commissioning a long-term custom platform.

Look at how work moves from an idea to production.

How are requirements understood?

How are priorities decided?

How is software tested?

How frequently can changes be released?

What happens when something goes wrong?

You might examine tools such as Jira, but don’t mistake having a tool for having an effective process. A beautifully organised Jira board can still describe a project that isn’t delivering.

I care more about whether people can answer basic questions:

• What are we working on?
• Why is it important?
• Who owns it?
• What is blocking us?
• When should it be finished?
• How do we know it works?

If delivery itself is a concern, an independent Project Delivery assessment can help separate technical problems from planning, leadership and communication problems.

10. Test Business Continuity and Recovery

Ask what happens when the technology fails.

Not if. When.

Every system eventually has an incident.

You want to know whether the business can respond.

Check:

• backup arrangements
• backup frequency
• recovery procedures
• disaster recovery plans
• business continuity plans
• incident management
• monitoring
• support coverage
• recovery responsibilities

Then ask one question that regularly exposes false confidence:

When did you last test restoring from backup?

Having backups and being able to recover from them are two different things.

A recovery plan that has never been tested is still largely a theory.

11. Look at the Roadmap and Future Investment

Your investment doesn’t end on purchase day.

What needs to happen during the next 12, 24 and 36 months?

Perhaps infrastructure needs replacing. A major framework is approaching end of support. Security improvements are overdue. The product needs substantial development to support growth.

These aren’t necessarily reasons to walk away.

They are costs and risks that should be understood before making the decision.

Ask for the technology roadmap and compare it with the business strategy.

If the business expects to expand internationally next year, can the technology support that?

If customer numbers are expected to triple, what needs to change?

If enterprise customers are the growth target, are security, reporting and integration capabilities ready?

Your Technology Strategy and commercial strategy should tell broadly the same story.

If they don’t, somebody needs to ask why.

A Practical Technology Due Diligence Checklist

Before approving a major technology investment, I would want clear answers across these areas:

Business

• What business problem are we solving?
• What outcome are we buying?
• How will success be measured?
• What alternatives were considered?

Financial

• What is the initial investment?
• What are the implementation costs?
• What are the three-to-five-year operating costs?
• What additional investment is likely?

Technology

• Is the architecture appropriate?
• Can it support expected growth?
• What technical debt exists?
• What systems and suppliers does it depend on?

Security and data

• What information is being stored?
• How is it protected?
• Who has access?
• How are incidents and recovery handled?

People

• Who holds critical knowledge?
• Is documentation adequate?
• Does the team have the required skills?
• What happens if key people leave?

Delivery

• Is there a credible implementation plan?
• Are responsibilities clear?
• Are timelines realistic?
• How will progress and risk be reported?

Commercial and ownership

• Who owns the intellectual property?
• What third-party licences exist?
• What contractual dependencies matter?
• How difficult would it be to exit?

You don’t need every answer to be perfect.

You do need the important risks to be visible.

Common Technology Due Diligence Mistakes

Treating It as a Technical Audit

Technology due diligence should connect technical findings with business consequences.

“Framework X is outdated” isn’t particularly useful to a CEO.

“This framework loses vendor support next year and replacing it is likely to delay your planned product expansion” is useful.

Relying on the Supplier’s Assessment

Your supplier naturally knows its product better than you do.

It is also trying to sell it.

Independent assessment provides a different perspective.

Reviewing Too Late

If the contract is signed and the deposit has been paid, your options have already narrowed.

Review before commitment wherever possible.

Looking Only at Today’s Requirements

Your investment needs to support where the business is going, not just where it is now.

Ignoring the People

This is the mistake I care about most.

Technology doesn’t operate itself. People design it, implement it, support it, change it and depend on it.

You can buy technically excellent software and still have a poor outcome if the organisation cannot adopt, manage or support it.

People before technology isn’t just a philosophy. It is practical risk management.

A Simple Decision Framework

After completing technology due diligence, classify findings into four groups.

Finding	Action
Acceptable	Proceed without material change
Manageable	Proceed with a documented mitigation plan
Commercial	Renegotiate price, scope, contract or responsibilities
Critical	Resolve before committing

This avoids a common trap where every technical issue gets treated as equally important.

They aren’t.

A minor documentation gap and an unresolved question about ownership of the core source code should not have the same weight.

Focus on business impact, likelihood and cost of remediation.

The final question is:

Knowing what we know now, does this investment still make business sense on the proposed terms?

That is the decision technology due diligence should help you make.

Frequently Asked Questions

What is technology due diligence?

Technology due diligence is an independent assessment of technology, costs, risks, people, security, suppliers and delivery capability before a major investment or transaction. It helps decision-makers understand what they are committing to and what problems may need to be addressed.

When should I conduct technology due diligence?

Ideally, conduct the review before signing a major contract, approving substantial expenditure or completing an acquisition. The earlier important risks are identified, the more options you have to address them.

Is technology due diligence only for mergers and acquisitions?

No. It can be useful before purchasing major software, commissioning custom development, investing in a technology platform, adopting AI, replacing an important business system or entering a substantial long-term technology agreement.

What’s the difference between technical due diligence and technology due diligence?

The terms are sometimes used interchangeably. Technical due diligence often concentrates more heavily on software architecture, code, infrastructure and security. Technology due diligence can take a broader business view covering those technical areas alongside people, suppliers, delivery, costs, governance and strategic fit.

Does technology due diligence tell me whether to make the investment?

It should give you better evidence for making that decision rather than make the commercial decision for you. A good review identifies risks, costs, dependencies and potential actions so you can decide whether to proceed, renegotiate, change the approach or investigate further.

Make the Decision With Your Eyes Open

A major technology investment doesn’t need to be risk-free. It needs to be understood.

The goal is to replace assumptions with evidence, identify the risks that actually matter and give you enough information to make a confident commercial decision. That is what good technology due diligence should deliver.