Nintex's own migration guidance concedes it: SmartForms have no automated importer, and workflow importers stub what they can't map. If your K2 estate is getting rebuilt either way, rebuild it once, on a platform with a future — with Marcus, Kinetech's AI Mendix developer, reading your K2 artifacts and proving every step with published evidence.
01 · The clock
Let's be precise, because your Nintex rep will be: K2 Five itself is not end-of-life — 5.9 LTS shipped December 2025. The pressure is everything around it, and everything behind it.
02 · The differentiator
K2 is unusually machine-readable for a legacy platform. Deployment packages, process definitions, and the SmartObject layer are all XML and open APIs — which means the functional specification of your estate can be extracted, not re-discovered in months of workshops.
| K2 artifact | What Marcus extracts | Where it lands in Mendix |
|---|---|---|
| Workflow definitions (.kprx / server-side) | Activities, steps, line rules, escalations, task assignments | Mendix Workflows (user tasks, parallel splits) + microflows; escalations via scheduled events |
| SmartObjects | Properties, methods, and which system each one fronts — SQL, SharePoint, CRM, REST | Entities plus first-class REST / SQL / OData integrations to the same systems |
| SmartBox objects | K2-managed tables and their data | Persistent Mendix entities, data migrated outright |
| SmartForms & Views | Layouts, controls, data bindings, form rules | Pages and reusable snippets with validation microflows |
| Deployment packages (.kspx) | The complete artifact manifest — every form, view, object, and workflow in the estate | The migration inventory itself: scored, triaged, quoted |
| Roles & AD groups | Role assignments and group usage across processes | Mendix user roles with Microsoft Entra single sign-on |
| Worklist | Task routing and actioning patterns | Mendix task inbox — one place your users action work |
The wedge, plainly: Nintex's own migration guidance says SmartForms are rebuilt by hand and workflow importers leave placeholders for unsupported actions. There is no lift-and-shift — from anyone. The question isn't whether to rebuild; it's whether the rebuild is manual and unverified, or extracted, evidence-gated, and landed on a platform you'd choose fresh today.
03 · How a migration runs
Four approval gates, held by you, govern every migrated process:
The extracted process spec — steps, rules, escalations, integrations, and what's being redesigned — approved before any model is written.
K2 roles and AD group assignments translated to Mendix roles and Entra SSO, presented in plain English for your sign-off.
Modern, branded design directions for the forms your users live in — presented before pages are generated. You pick; Marcus builds to it.
Each process reaches you only after all quality gates pass — and goes live only when you accept it, evidence in hand.
04 · The date
Here is the commitment we will put in writing. The assessment does not end with a range — it ends with a date, sized from your actual extracted complexity. Miss that date and the assessment fee comes back. We can promise a date because we never quote a calendar before reading your source.
The assessment names the date. Miss it, and the assessment fee comes back.
That is a real term, not a slide. It is affordable to us for one reason: the clock below starts only when a complete artifact pack is in our hands, and it pauses only for your own approval gates.
| One K2 process plus its forms | Complete artifact pack → UAT-ready |
|---|---|
| Compact — one process, ≤10 activities, ≤5 SmartForms | 2–3 weeks |
| Departmental — 1–3 processes, 10–40 activities, SmartForms and SmartObjects over 2–4 systems | 4–6 weeks · ~30 days typical |
| Load-bearing — process families, custom service brokers, K2 for SharePoint, heavy .NET extensions | 8–12 weeks |
| Each further process in the same estate | 30–40% faster |
Sizing model, not a price list — the assessment reads your actual source and returns one date. Bands assume a single rebuild boundary agreed at the scope gate.
The date is only honest if the inputs are complete, so here is the whole list up front. Nothing on it is unusual, and most of it exists already.
Three approval gates are yours: scope, permission ratification, design sign-off. We answer each within three business days. Time beyond that on your side moves the date by exactly that much — and nothing else does.
Production cutover on your change calendar. SSO and network provisioning by your IT. Third-party licenses or vendor contracts we don't control. Remediation of source-data quality problems the assessment flagged. Anything added after the scope gate.
Functional parity against the approved specification, running on your migrated data in a parallel environment, with production security enforced and tested per role, all nine quality gates green, and documentation published. Your users click through it.
The process definition is XML and extracts cleanly. What moves a K2 date is the SmartObject layer — every service broker is a real integration and gets scoped as one — and the in-flight instances, which run down on your calendar under a separate plan and are not part of this clock.
05 · Why Mendix
Your realistic options are Nintex Automation Cloud, the Power Platform, or a real application platform. For estates built on SmartObjects over SQL with multi-step human workflow, the shape of K2 maps to Mendix almost one-to-one.
06 · Straight talk
| Area | The honest position |
|---|---|
| In-flight process instances | Nobody migrates running instances cleanly — K2 itself ships a Live Instance Management API precisely because version moves are hard even within K2. The plan is a run-down: new cases start in Mendix, the K2 worklist drains to zero, and only genuinely long-running processes get explicit state migration, scoped in the assessment. |
| Custom service brokers & .NET code activities | No automated path exists anywhere — Nintex's importers stub these too. Custom code becomes explicit integrations or Java actions in Mendix, identified up front in the assessment and priced in the spec you approve, never discovered mid-project. |
| Reporting history & audit trail | K2's reporting tables are queryable SQL. History archives to your warehouse or imports as read-only records in the new app. We do not promise live continuity of K2's own reports — and you shouldn't believe anyone who does. |
| SmartBox data | Migrates outright — it's SQL Server data K2 manages, fully extractable. |
| Deep SQL / AD integration | Transfers well: Mendix connects to the same databases natively and authenticates against Entra — without a vendor gateway server in the middle. |
| Process redesign | A rebuild is the right moment to fix a process, but scope creep kills migrations. The default is faithful re-implementation; redesigns are called out separately in the spec so you choose them deliberately. |
07 · Quality & security
Watch real build evidence land on the live Build Console, and see the delivery lifecycle at our interactive explainer.
08 · Engagement & pricing
Package export and automated read of your estate: a scored inventory (rebuild / retire / consolidate), custom-code and broker flags, in-flight instance analysis, and fixed-bid quotes for the first rebuild wave.
Credited toward onboarding if you proceed.
Each workflow quoted from its actual extracted complexity — steps, forms, integrations, custom code — not a day-rate guess. Built, tested per role, documented, delivered through the approval gates.
Best for a first wave of 3–10 processes.
For larger estates: a Marcus instance works your migration backlog continuously. Priced on what the work is, how many lanes run in parallel, and how fast you need it — always with Kinetech engineer review and an escalation SLA.
Bring your own Claude access: roughly 15–25% off the monthly.
Every figure here is an indicative range; your actual range is confirmed in writing before anything is charged. On bundled plans, heavy build months may incur metered usage beyond the included allowance; your quote states the allowance plainly. Your applications, models, and repositories are contractually yours.
09 · The questions you should ask
Correct, and we won't pretend otherwise — 5.9 LTS shipped December 2025 and Nintex is still investing. But look at what staying current now costs: blackpearl support is gone, 5.6 support ends August 31, 2026, and the 2026 dependency retirements Nintex itself documents (Exchange Web Services, .NET 8) each force fix-pack upgrade projects. Meanwhile Nintex's cloud endgame is a re-platform whose own importers can't carry your forms. You're paying to stand still on a platform whose exit is a rebuild regardless of when you take it. Earlier is cheaper and calmer than later.
You're right — and no one can, cleanly. K2 ships a Live Instance Management API because moving running instances is hard even between K2 versions. That's why the plan is a run-down, not a cutover: freeze new starts per process, open new cases in Mendix, and drain the K2 worklist to zero. Long-running processes (multi-month approvals, retention holds) get explicit state migration, identified and priced in the assessment. Your users see one switch date per process, not a big bang.
That's the honest hard part, and it's where migration quotes go wrong — so we surface it first. The assessment inventories every custom broker and code activity from your packages before anything is quoted. Each becomes an explicit REST/SQL integration or a Java action in Mendix, stated in the spec you approve. Nintex's own importers stub these as placeholders; we price them as work, visibly, up front.
Read Nintex's migration guidance closely — we did. Forms have no automated importer ("rebuilding takes hands-on effort," in their words), workflow importers map only supported actions and leave placeholders for the rest, and reaching your on-prem SQL and AD requires running a Nintex Gateway server. So the move to their cloud is a hand rebuild of your forms onto a workflow tool that keeps a foot on-prem anyway. If that's the real price, compare destinations honestly — including one where the whole application lives in one governed platform.
It's SQL — K2's reporting tables are queryable, and the history is extractable. Depending on your retention needs it archives to your data warehouse or imports as read-only records alongside the new app. What we won't promise is live continuity of K2's own report screens; the honest deliverable is your history, preserved and queryable, plus a better audit trail going forward — every action in the new apps lands in a tamper-evident ledger.
Yes — that's the design. The output is standard Mendix in your Team Server: your team opens it in Studio Pro, diffs it, merges it, extends it. Every model ships with 100% in-model documentation, a full test suite, and visual user guides. If you cancel, you keep everything and any Mendix shop continues where Marcus left off — portability is the proof the work is real.
Everywhere, by construction. You approve each process spec before build; you ratify the permission model; you accept each release with the evidence — per-role journey tests, security scans, the scorecard — in front of you. A Kinetech engineer reviews every release before it reaches you, with an SLA where you have taken one on escalations. Nothing cuts over on Marcus's say-so; it cuts over on yours.
10 · Next step
Pick a simple approval, a workhorse process, and your gnarliest workflow — the one with the custom broker. We'll run the extraction and return scored specs: what transfers, what needs redesign, and a fixed price to rebuild each — inside two weeks. Judge the approach on your own estate, not on a slide.
Marc Lehane · Solutions Architect / CTO, Kinetech · [email protected]
Kinetech Cloud · San Antonio, TX · How we deliver · Live Build Console
You are reading Your platform — deeper detail on step 4, Why now?.
That is the pressure. What it costs to answer it is not one number — three things move it.