Answers to the questions that come before a project.

The right alternative depends on your operating model, not on a vendor shortlist. Here are the six categories, what each one costs, and how each one fails.

A renewal date is a deadline, not a strategy. This is what is actually negotiable, what can be built in the time you have left, and what to refuse to sign.

Data migration is where ERP replacements overrun. This is the checklist we work from, in the order the decisions have to be made.

Leaving NetSuite fails when it is treated as a single event. This is the operational sequence that keeps dispatch, billing, and the field running while the system underneath them changes.

Leaving NetSuite is an operations project with a software deliverable attached. The replacement platform is rarely the largest number on the page.

The decision is not custom versus platform. It is which parts of your operation are the same as everyone else's and which parts are the reason customers choose you.

Most ERP complaints describe a configuration problem, not a platform problem. This is how to tell the difference before you spend a year finding out.

Every business runs on internal tools, whether or not anyone decided to build them. This is how to tell which ones deserve real engineering and which are fine as they are.

You cannot prioritize an estate you cannot see. An inventory is a two to three week exercise and it usually finds at least one dependency nobody knew existed.

Internal tool builders are very good at a specific shape of problem and poor at another. The useful skill is telling which one you have before you commit.

We have built a business on no-code tooling and then deliberately replaced it. This is how to tell a ceiling you can work around from one that means it is time to move.

The dispatch board, the job tracker, the inventory sheet. This is how a multi-user operational spreadsheet fails, what fixes buy real time, and where those fixes run out.

A surprising number of businesses run a critical process on an Access database built years ago by someone who has left. This is how to replace one without losing what it knows.

Spreadsheets are excellent and most of yours are fine. This is how to tell which one has quietly become a system of record, and what the smallest useful fix is.

An assessment is a deliverable, not a meeting series. This is the specification: what gets inventoried, what comes out of it, and what a bad one looks like.

Continuous operation during a rebuild is not a promise, it is a set of engineering practices. These are the ones that decide whether the migration survives contact with real users.

Rewrites rarely fail because the new stack was wrong. They fail on scope, on undocumented rules, and on attention that runs out before the money does.

The strangler fig pattern is usually explained as a routing diagram. The part that decides whether it works is data ownership during the years the two systems overlap.

The question is almost never whether to rewrite or refactor the whole system. It is which parts belong in which category, and what evidence should decide it.

Most stalled offshore builds are a structural mismatch rather than incompetence. What matters now is an honest assessment of the asset before anyone decides to restart.

Most companies discover what they actually own at the moment they need it most. This is what ownership consists of, how to ask for a handover, and how to structure things so the question never comes up again.

One person built it, ran it, and held all of it in their head. This is the order of operations for the first 48 hours and the weeks after.

An audit is worth doing only if it ends in decisions. This is the order to work in, what each finding actually costs to fix, and how to rank the results.

A handover is a logistics problem before it is an engineering problem. This is what must change hands, what the overlap period buys you, and how the incoming team should spend its first two weeks.

Sponsors usually sense a project is failing months before they can prove it. This is how to get evidence quickly and decide what to do with it.

Connecting a CRM to an ERP is rarely a transport problem. It fails on ownership, identity, and money, in the same seven places every time.

Most broken integrations were never engineered to fail well. This is the set of controls that separates a connection you can operate from one that surprises you.

Low-code automation platforms and purpose-built integration code solve the same problem at different costs. This is how to tell which one your situation calls for.

Moving a record between two systems is a small job. Everything around it (retries, reconciliation, monitoring, and edge cases) is where the money goes.

These are two different jobs that get bought as one product, and the product usually satisfies neither. Here is how the requirements diverge and how to tell which one you are being asked for.

The question usually arrives attached to a slow report, a missing number, or a spreadsheet someone rebuilds every month. A warehouse is rarely the smallest thing that fixes any of them.

Most teams read the phrase as "one system", which is neither achievable nor the fix. What you need is one authoritative source per entity, written down and enforced.

When two systems disagree, the cause is almost never a bug. It is usually two correct answers to two slightly different questions, and the fix is a written definition rather than a new tool.

Human review only works when it is designed. This is how to place it, what to put in front of the reviewer, and how to tell whether the check is real.

Most AI features are judged by whether a demo felt impressive. This is how to define acceptance in business terms and prove the feature clears it before anyone depends on it.

Industry lists are a poor guide to AI use cases. The shape of the task (extraction, routing, drafting, reconciliation) predicts whether it will work.

A demo proves a model can do something once. Getting to a system people depend on is integration, ownership, evaluation, and fallback work, and that is where pilots stall.

A pricing model is an operating model decision, and almost nobody evaluates it that way at purchase. This is what per-seat licensing does to a field operation.

The gap between finishing a job and sending the invoice is a cash-flow problem before it is a software problem. This is how to find the days and remove them.

Offline support is not one feature; it is three levels with sharply different price tags. This is what each level buys, where the real engineering cost sits, and when full offline editing is not worth building.

A dispatch system technicians route around produces worse data than a whiteboard, because the office believes it. This is what the job actually demands of the software.

Shared logins are usually a rational answer to per-seat pricing and slow account setup. They are also the control that quietly disables every other control you have.

Most systems log something; few can answer the question an auditor, a customer dispute, or an internal investigation actually asks. This is what separates a trail you can rely on from one you cannot.

An enterprise customer has asked for a SOC 2 report and you have never been through one. This is what it typically demands of the software and the engineering process around it.

Once a business runs more than one location, roles stop being enough. Scoped access is one of the few requirements that genuinely multiplies the cost of a system, and it is almost never in the initial brief.

Team size is usually chosen from a budget rather than from the work. This is what each shape is actually good at, and how coordination cost decides the answer.

Headcount only helps when capacity is the thing you are short of. Most slow projects are short of decisions, review capacity, or a working environment.

Most of the first month an outside engineer spends getting productive is spent waiting on things you could have prepared. This is what to prepare.

The title is used loosely and is sometimes sold as a retainer with no deliverable. This is the work that genuinely requires a senior technical leader, and the common case where you need something else.

A permanent engineer is justified by continuous change to a system the business depends on, not by a project that has an end date. This is how to tell the difference before you make an offer.

Three engagement shapes are routinely described with identical language and fail in completely different ways. This is what each one actually commits to.

The integration plan written during diligence is usually wrong because it assumes consolidation is desirable everywhere. This is how to decide what actually has to merge, and when.

Technical diligence produces a long list of findings, and most of them do not matter. This orders them by what they actually do to a transaction, from deal-breaking down to hundred-day plan.

Diligence is not a code audit. It answers what you are buying, what it will cost to own, and which findings should change the price or the terms.

Discovery fails when it collects what people say they need instead of what the work actually requires. This is how to run a session that ends with recorded decisions rather than a wish list.

Operational software is judged in its first two weeks, not at handover. This is how to shape the switch, train close to it, and staff the days when the questions arrive.

The people avoiding your new system are optimizing for something real, usually their own throughput. Adoption returns when the system stops costing them time.

Build versus buy is rarely a whole-system decision. It is a boundary you draw through your operations, and drawing it in the wrong place is the expensive mistake.

The comparison is almost always made on hourly rate, which is the one number that does not predict what you will spend. This is the comparison on the unit that does.

The overhead in a low-rate engagement is real, but it is paid in your staff's time rather than on the invoice. This is how to find it and put a number on it.

Rate cards make US-based delivery look like a premium purchase. Priced per delivered increment, the comparison usually looks different.

Most selection processes compare rates, logos, and slide decks, none of which predict delivery. These are the criteria that do, and the questions that surface them.

The contract model decides how both sides behave long before anyone writes code. This is what each one does to incentives, written by a vendor about vendors.

Most published estimates are marketing. This is how custom software is actually priced, what moves the number, and where budgets quietly break.

Metro Atlanta's industry mix produces a recognizable set of operational software problems. This covers what those problems look like and where working with a local team genuinely helps.