Digital Transformation Consulting: What to Expect and How to Choose

Digital transformation consulting is paid outside help to change how a company works by changing the software it runs on. In practice that means deciding which processes should come off paper, spreadsheets and email first, choosing what to buy and what to build, moving the data across and getting people to actually work in the new system. A good engagement starts with one or two processes, puts a working system in front of real users within a few months and measures it against how things ran before. If all you hold at the end is a maturity score and a roadmap deck, you have paid for the cheapest part of the work.

We're a small software team in Ankara, and we see this work from the delivery end. Clients bring us in to build the custom applications, integrations, automations and data migrations that a transformation plan eventually turns into. The examples below come from that work, including the parts that broke.

Three kinds of firm sell this

The same label covers very different services, so it helps to know which kind you are talking to.

Most companies need some of each at different times. More important than the type of firm is that one named person is accountable for the result in production, and that whoever gives the advice is still around when it is put into practice.

What you should hold at the end

• a description of each chosen process as it runs today, with volumes, handling times and error rates
• a decision for each step: change the process, configure a product you already have, buy something new or build
• a working system for the first process, used by real people, with the old way retired or on a dated path out
• migrated data that someone on your side has reconciled against the old system
• code, configuration, data and cloud accounts in your company's name, with documentation another team could work from
• a short, costed list of what comes next (our notes on building a digital transformation roadmap cover that list)

When you need a consultant and when you don't

You can usually skip the consultant when:

• The need is a tool most companies use in the same way, such as accounting, payroll, e-invoicing or a helpdesk. Pick a product and use the vendor's onboarding. An assessment beforehand rarely changes the choice.
• You already know which process hurts and roughly what should replace it. Then you need a team that can configure or build it, and perhaps a part-time technical lead to check the vendors' work. We wrote about the fractional CTO model for that case.
• Nobody inside the company will own the change. A consultant can't supply an owner, so find one first.

Outside help earns its fee when:

• the process crosses several departments and systems, and nobody sees the whole flow
• the systems involved don't connect, so the work lives in exports, re-typing and email
• data has to come out of an old system the business still depends on every day
• you need someone independent to judge vendor proposals
• personal data is involved, so the choice of tool has legal consequences (in the EU, any SaaS product that processes personal data on your behalf needs a processor contract under Article 28 of the GDPR)

How a good engagement runs

A short discovery, where "stop" is an allowed answer

The UK government's Service Manual describes discovery as understanding the problem before you commit to building anything. It puts the typical length at around 4 to 8 weeks, says you should not start building during it, and says that stopping at the end is not a failure if the research points that way. The same rules work for a private company. Ask a consultant what would make them recommend stopping. If they can't name anything, the discovery is a sales phase.

Discovery should produce a baseline for each process you might change: cases per day, minutes per case, how often something goes wrong and what a mistake costs. That takes a few days with a spreadsheet and the people who do the work. Without a baseline, every ROI figure that follows is a guess.

One process, with an owner

Good first candidates are done by hand every day, follow rules someone can write down, and have one person who will check the output and say when it is wrong. Keep the first step that small: one process, and one team that checks what the new system produces.

An example from client work: an oilfield services company in Canada produces a PDF field ticket for every job, and someone had to read each one for the customer, location, AFE/PO number, line items and operating, standby and transit hours before it could be invoiced. With an automation agency partner, we built an n8n workflow that collects the day's tickets from Gmail every evening, extracts that data with an LLM, files each PDF with its data in dated Google Drive folders and emails a consolidated report to the billing team. The work started in July 2025. We tested extraction on real tickets for a month before going live in September 2025, and the workflow has handled about 100 documents a day since then.

Decide each step on its own merits

Once a process is mapped, some steps turn out to be unnecessary. Others are covered by software you already pay for. Build only where the work is specific to your business or sits between systems that no product connects. Our notes on custom software vs off-the-shelf go through that decision in more detail.

Keep the old way running until the new one has proved itself

Tribute Technology, a US funeral-home software company, onboarded each new customer by importing years of case data from the customer's previous system by hand: MSSQL backups, MySQL databases, CSV exports. We won the work through an RFP in 2022 and built a platform where staff map fields, re-run versioned mappings and approve the results before export. While it was being built, we did 11 conversions by hand so onboarding never paused. Tribute stopped manual imports in favour of the automated process in February 2023. Its product owner judged success by matching migrated data against A/R reports, case counts and spot checks.

Agree on checks like these before the switch. Totals from reports the business already trusts are much easier to argue from than a vendor's own test results.

Assume the source data is messier than it looks

Oplist, a client we build for, is a hospital shift-scheduling SaaS, and we have been its engineering team since November 2023. It has live API integrations with the HR and payroll systems of private hospitals in Türkiye and receives staff and leave data from them. The integration has to carry the type of leave (sick leave, hourly leave, block leave such as training), because the scheduling rules depend on it and a plain "unavailable" flag isn't enough.

The source systems can also contain duplicate staff records, and some leave types take precedence over others when they overlap. We handle both inside Oplist, deduplicating staff and applying a precedence order, instead of trusting the data as it arrives. When we moved Oplist from Flutter Web and Flask to React and Node.js, the hardest parts were time and data integrity.

If your transformation involves moving or syncing records, put a cleanup step in the plan and decide early who in your company has the final word on which record is right.

Plan for what breaks after go-live

In the field-ticket workflow, the LLM steps were what failed, mostly when the model provider's API returned rate-limit errors (HTTP 429). We added fallbacks to alternative models, so a document still gets processed when one model is unavailable. Every new system has some version of this problem. Before launch, agree who receives the alert, what the fallback is and who pays for the fix.

Take everything over at the end

In September 2023 we moved Tribute's production code into its own repositories and AWS account, with installation and architecture documentation. Put that in the contract from day one: code, configuration, data, cloud accounts and admin access in your company's name, and documentation good enough for a different team to carry on.

Why so many transformations disappoint

In October 2020 BCG published research, combining a survey of 825 senior executives with its own work at 70 companies, which found that 70% of digital transformations fall short of their objectives. The executives rated their own programs, so treat the number as a rough signal.

The six success factors in the same report are more useful than the headline, and five of them are about how the company is run: an integrated strategy with clear goals, commitment from the CEO down through middle management, strong people on the work, governance that adapts as you learn, and monitoring progress against defined outcomes. The sixth is a modular technology and data platform led by the business. When you interview consultants, ask which of these they will actually take responsibility for.

How to contract it, and what the fee leaves out

We know of no reliable public price list for this work, and quotes move a lot with scope. Compare what each quote includes before you compare the totals.

The shape of the contract matters as much as the rate. The common options:

• a fixed-price discovery with a defined output and an end date, which caps your risk while you find out whether the team is any good
• fixed milestones for a build whose scope is clear (Tribute ran this way: 13 milestones, followed by maintenance)
• a long-term product team for work that keeps changing (how we have worked with Oplist since November 2023)
• an advisory retainer, a set number of hours a month, for oversight while another team builds

Costs that sit outside the consulting fee:

• software licenses, often priced per user per year
• integration between the new tools and the systems you keep
• data cleanup and migration
• training, and your own staff's time while two ways of working overlap
• hosting, monitoring and maintenance after launch

Ask for each as a separate line in the proposal, with maintenance priced per month or per year.

Warning signs in a proposal:

• a long assessment phase that ends with nothing built and no decision
• fees tied to "savings" when nobody has measured the starting point
• licenses resold at a margin the consultant doesn't disclose
• senior people in the pitch whom you never see again once the work starts

Questions to ask before you sign

1. Which past project is closest to ours, and can we speak to that client?
2. Who exactly will do the work, and how much of their time is ours?
3. What will be running in production after the first three months?
4. How will we measure whether it worked, and who measures the starting point?
5. Which products do you resell or earn commission on?
6. What would make you recommend that we stop?
7. Who owns the code, data, accounts and documentation, and how does handover work?
8. After launch, who supports the system, how quickly, and at what cost?

Frequently asked questions

What is the difference between digitization and digital transformation?

Digitization turns something on paper into data, such as a scanned form or a PDF invoice. Digital transformation changes how the work gets done once the data exists: who does what, which system holds the correct version, what happens automatically. The first is often a step toward the second.

Do small companies need a digital transformation consultant?

Usually not. A company of a few dozen people tends to get more from picking its most painful process and paying a team to fix it, with a part-time technical lead alongside if nobody inside can judge the work.

Can a software development company do digital transformation consulting?

For the process and systems side, yes, and it has the advantage of having to build what it recommends. For organization design, restructuring or board-level strategy, a management consultancy is the better fit.

If you have a process you'd like to move off spreadsheets and want a second opinion on whether to buy, configure or build, send us a short description.