Switching engineering firms mid-project is expensive, disruptive, and sometimes clearly the right decision. The rule of thumb: replace a firm when the problem is capability or conduct, and fix the relationship when the problem is communication or scope. Before you announce anything, collect every file you are entitled to, read your contract, and line up the replacement. Handled in that order, a transition costs weeks. Handled badly — announcing first, collecting later — it can cost you the design.

This is practical guidance from an engineering perspective, not legal advice. Projects House is an engineering firm; contract termination questions belong with your attorney.

The decision nobody wants to make

Every switch costs a ramp-up: the new team must read, rebuild, and re-validate work you already paid for, typically two to six weeks before net new progress resumes. That cost is real, and it is why the honest first question is not "should I switch" but "what exactly is going wrong, and is it fixable with this team?"

Signs that justify a change

  • Repeated missed milestones with no revised plan. Slippage happens. Slippage with no explanation and no new schedule is a management failure.
  • Deliverables you cannot verify. Progress described in adjectives, never in files, drawings, or test data.
  • The work is outside their real competence. A firm strong in mechanics learning firmware on your budget is a common and expensive pattern.
  • Costs escalating without corresponding scope. Especially where time-and-materials billing has no cap and no burn reporting.
  • Refusal to hand over source files — native CAD, schematics, firmware source — that your contract entitles you to. This is a serious red flag on its own.
  • Key people gone. The senior engineer who won the project left and juniors inherited it.
  • Design decisions that ignore your requirements after being raised in writing more than once.

What does not justify a change

Be honest about the other half of the ledger. Bad news delivered clearly is good service, not failure — a firm telling you the concept will not hit your cost target is doing its job. Slow progress caused by your own late decisions is not their fault, and neither is a schedule that slipped because you changed requirements twice. Scope disputes usually trace back to a vague statement of work, which is a documentation problem you can fix. And personality friction is rarely worth a restart. Before switching, try one structured intervention: a written summary of the gaps, a meeting with whoever owns the firm rather than the project manager, and a two-week corrective plan with specific deliverables. Firms often respond, and if they do not, you have documented the reason.

Before you announce: collect everything

This is the step people get wrong. Once a firm knows it is being replaced, cooperation tends to decline. While the relationship is intact, request — as normal project hygiene — the full current state of the work:

  • Native CAD files, not just STEP or PDF exports, including assemblies and configurations.
  • Schematics, PCB layout source, and gerbers; the bill of materials with real part numbers and sources.
  • Firmware source with version history, toolchain versions, and a build that compiles from a clean checkout.
  • Test reports, calibration data, and analysis results.
  • Supplier and vendor contacts, quotes, and any tooling status or ownership documentation.
  • Drawings, tolerances, and any certification correspondence.

The complete list is essentially our manufacturing data package. Verify what you receive actually opens and builds — a folder of files is not a handover. If the source is genuinely unavailable and only physical parts or exported geometry exist, the new team faces a partial reverse engineering exercise, which you should price in.

The contract side

Read your agreement before you act. The clauses that matter are termination notice and any fee, ownership of work product — see who owns the IP in product development — whether ownership transfers only upon full payment, deliverable acceptance criteria, and what happens to prepaid retainers or amounts held against milestones. Settle outstanding invoices for accepted work; disputes over a final payment are the most common reason files get withheld. Get the handover obligation confirmed in writing as part of the termination.

Choosing the next firm — differently this time

Do not repeat the selection process that produced the problem. Ask candidates specifically how they take over partially completed projects, and expect a paid technical assessment of the existing design before any new development is quoted — that is what technical due diligence is for, and it also tells you how the new team thinks. Verify the disciplines you actually need are in house. Ask to speak to a client whose project the firm inherited. And read the red flags when hiring an engineering firm and how to compare engineering quotes before you sign anything.

Managing the transition

Structure the first phase with the new firm as a paid review, not a continuation. They read the package, build or test what they can, and deliver a written assessment: what is sound, what must be redone, what is missing, and a revised plan with cost and schedule. Expect some rework — a new team that adopts an unverified design wholesale is taking a risk on your behalf. Keep the old firm reachable for questions if the relationship allows it, freeze requirements during the transition so the new team is not chasing a moving target, and only then resume forward development.

Considering a change?

Projects House takes over in-flight projects regularly, usually starting with an honest assessment of what already exists. Tell us through the contact form where your project stands and what you have in hand, and we will tell you what it would take to move it forward.