Most Nintex deployments do not fail loudly. They drift — scope discovered late, environments improvised, migration treated as a copy, testing squeezed, and a launch week where nobody is sure which version is live. Twopir Consulting runs Nintex implementation as a defined project with gates, environments and a cutover plan. Design, build, migrate, validate, launch and hypercare.
A Nintex implementation is the work of taking an agreed automation design into live, supported production: standing up and configuring the environments, building the workflows, forms and document templates, connecting them to the systems that own the data, migrating what already exists, testing it against real cases, and running the cutover. It ends at a documented handover, not at the first successful test.
| Workstream | What we do | What you have at the end |
|---|---|---|
| Platform setup | Tenant and environment configuration, user and group provisioning, role and permission model, connection and credential management. | A dev, test and production environment with a documented promotion path and no shared admin credentials. |
| Solution build | Workflows, forms, tasks, business rules and document templates configured to an agreed naming and structure convention. | A build that a different consultant could pick up and extend, because it follows a written standard. |
| Integration | Connectors configured or built, authentication established, field mapping agreed, retry and failure behaviour implemented. | A documented data contract per integration: direction, owner, frequency and failure path. |
| Migration | Inventory of existing workflows and templates, classification into retire / rebuild / replace, and migration of the ones that survive. | A smaller, deliberate estate — plus a written record of what was retired and why. |
| Test & UAT | Functional, integration and negative testing, then structured user acceptance with real scenarios and real data volumes. | A signed UAT record and a defect log closed to an agreed threshold before cutover. |
| Cutover & hypercare | Cutover runbook, handling of in-flight work, staged enablement, and elevated support through the first live cycles. | A launch that was rehearsed, and a support period with a defined end date rather than an open one. |
| Handover | Architecture documentation, build conventions, runbooks for the failure paths, and enablement for the team that will own it. | The ability to change your own estate without calling us first. |
Not every Nintex build needs an implementation partner. These are the ones where doing it alone reliably costs more than it saves.
The conventions you set in the first ten workflows become the conventions for the next two hundred. Getting naming, environment strategy and error handling right at the start is cheap; retrofitting them is not.
Classic SharePoint workflow and InfoPath support has ended, which puts a real date on estates that were built around them. The logic has to be rebuilt on a current platform, not copied across.
Once CRM, ERP, a document store and an eSignature provider are all in one process, the hard part stops being the workflow and becomes the data contract between them.
When approval sequence, thresholds, segregation of duties and retention have to be evidenced, the build has to be designed against the control, not adjusted to satisfy it afterwards.
Capable analysts who have not built at this scale before spend their first project discovering the patterns. We supply the patterns and coach the team through using them.
A contract renewal, a platform end-of-support, a merger, an audit. Fixed dates need gates, a critical path and a cutover rehearsal — not a backlog and good intentions.
The gates are the method. A phase does not start because the calendar says so — it starts because the previous one produced its deliverable and someone named signed it off.
We document the in-scope processes end to end and, where an estate already exists, inventory every workflow, form and template with its owner, usage and dependencies. Output is a scope statement with an explicit retire list. Gate: scope signed.
Data contract per integration, workflow and form structure, exception and escalation paths, permission model, environment and release strategy, and the build conventions the estate will follow. Gate: architecture approved.
Configuration in a non-production environment against those conventions, connectors wired and authenticated, retry and escalation implemented, and every workflow peer-reviewed before it leaves development. Gate: build review passed.
Functional and integration testing, then deliberate negative testing — timeouts, throttling, missing records, absent approvers — followed by user acceptance on real scenarios at realistic volume. Gate: UAT signed off.
A rehearsed cutover: what stops, what starts, what happens to work already in flight, who decides to proceed and what the rollback is. Staged by team or process where the risk profile justifies it. Gate: runbook rehearsed.
Elevated support through the first live cycles, defect triage against an agreed threshold, then documented handover: architecture, conventions, runbooks and enablement for the people who now own it. Gate: handover accepted.
Five choices made in the first fortnight determine how much the estate costs to run for the rest of its life. They are boring, and they are the ones teams skip.
Development, test and production as genuinely separate environments with their own connections and credentials. Building in production is faster for exactly one sprint, and then it is the reason nobody dares change anything.
A documented path from development to production, with the connection and environment-specific values parameterised rather than hard-coded, so a promotion does not require a manual re-point of every action.
Workflows that run as a named service identity with scoped permissions, not as whoever happened to build them. The alternative is an estate that breaks on the day that person changes role.
A naming scheme for workflows, variables and actions, descriptive action labels, and action sets grouping related logic. This is what makes a workflow readable to the person who inherits it.
Every process gets a named business owner and a named technical owner, and a defined route for requesting a change. An estate without owners does not stay documented past its first quarter.
Deciding what you will measure before go-live, so the baseline exists. Retrofitting measurement means the improvement can never be evidenced. See Nintex analytics and reporting.
Microsoft's retirement of classic SharePoint workflow and InfoPath put a hard date on a large number of Nintex estates. There is no button that moves them. Importer tooling gets part of the way and the rest is a redesign — which is the opportunity, not the problem.
| Path | Choose it when | What the work really is |
|---|---|---|
| Move to the Nintex cloud platform | There is no hard data-residency or hosting constraint, and you want the current feature set and release cadence. | Rebuild on current designers with the logic re-expressed, not copied. SharePoint-specific actions have no direct equivalent and need a design decision each. |
| Move to the on-premises Nintex line | Data residency, hosting policy or a regulated workload requires the platform to stay inside your estate. | Importer tooling accelerates the transfer of structure, then the same redesign work applies. Plan for infrastructure, identity and upgrade ownership too. |
| Rebuild elsewhere | The surviving processes are few, simple, and already native to a platform you run — or the process should be retired. | An honest reassessment. If eight of your forty workflows matter and four of those are a CRM feature, that is the finding, and we will say it. |
| Retire | The workflow has not run in months, its owner has gone, or the process it served no longer exists. | Confirm it is genuinely dormant, record the decision, and stop paying to carry it. In most estates this is the largest single category. |
We inventory first and decide second. Migrating an estate before classifying it is how organisations pay to move workflows nobody has run since 2019 — and then pay again to maintain them.
Implementations slip on client-side decisions far more often than on build effort. Naming these up front is the single cheapest way to protect the date.
One person who can settle a process disagreement inside a week. Design questions that go to a committee are the most common cause of a missed gate.
Environments, connected systems, test accounts and sandbox data. Access requests raised in week six become a two-week delay in week seven.
The people who will use it, testing real scenarios, with the time protected in their calendar. UAT done in spare moments finds nothing and signs off anyway.
Including the workarounds. The undocumented spreadsheet step that everyone relies on is exactly the thing that breaks a go-live when it surfaces in week one of production.
Identified during the project, not after it, and involved through build and testing. Handover to a person who first saw the system at handover is not handover.
The advisory layer above delivery: which processes to automate, in what order, and whether Nintex is the right answer at all.
The build craft inside phase 03 — branching, loops, task routing and error handling, covered in design-level depth.
The integration workstream in full: which system owns which field, sync direction, and reconciliation design.
Where the engagement starts instead, when the estate already exists and the problem is what is running today.
Where the process produces a quote, contract or pack, the template architecture is scoped as its own workstream rather than discovered in phase 03.
For the requirements that standard configuration will not meet — triaged during design, so the build estimate reflects them.
Yes, and it is usually the better model when you intend to own the estate afterwards. A common split is that we own architecture, the integration layer and the build conventions, while your team builds a growing share of the workflows under review. The gates and the peer-review step stay the same regardless of who did the build.
Almost certainly not, and assuming you must is the most expensive decision available. We inventory the estate and classify each workflow by actual usage, owner and dependency. Dormant workflows, duplicates and processes that no longer exist get retired with the decision recorded. Migration cost scales with what you carry forward, so the inventory usually pays for itself before the build starts.
It is a design decision made during phase 05, and there are three usual answers: let in-flight instances finish on the old platform while new ones start on the new one, pause new starts and drain the queue before cutting over, or migrate in-flight state where the process is long-running and draining is not realistic. Which one applies depends on how long the process runs and whether a partially completed instance has legal or financial standing. It is written into the runbook and rehearsed before launch day.
Discovery is scoped and priced on its own, because it is the phase that makes the rest estimable. After discovery you get a phased estimate tied to the agreed scope, with the integration and migration workstreams costed separately — those are the two that move most when reality differs from the brief. We would rather re-baseline visibly after discovery than quote a number before anyone has seen the data.
Yes, and we start with an assessment rather than by resuming the build. What exists gets reviewed against what was actually agreed, and we report plainly on what is usable, what needs rework and what should be abandoned. Occasionally the honest answer is that the design is sound and the project needs governance rather than more build effort — that is a cheaper finding to act on than to ignore.
It is scoped to cover the first complete cycles of the process rather than a fixed number of weeks, because a monthly close and a daily approval have very different risk profiles. It has a defined end date and a defined exit condition — typically defect volume below an agreed threshold and the client team resolving issues without us. If you want ongoing support after that, it becomes a separate arrangement rather than hypercare that quietly never ends.
Whether you are starting fresh, moving off a SharePoint-era estate, or restarting a project that stalled, the first conversation is about scope, constraints and the critical path — not a demo.
Implementation delivery with gates, environments and a rehearsed cutover
