The first thing to settle on a bot migration is how long the old UiPath bot has to keep running once its replacement is built. The answer people hope for is one weekend. It is longer than that, and the reason has almost nothing to do with the quality of the rebuild. Two of June's vendor releases moved numbers that bear on how we size a parallel run, so this is a reasonable month to set out how we size it, and which parts of it we think are worth arguing over.
Why a single weekend cutover goes wrong
The plan we are usually handed is to rebuild the process, test it in UAT, switch the new one on over a weekend, and disable the UiPath schedule on Monday. It is easy to put on a schedule and it goes wrong often enough that we no longer offer it as the default. Most of the trouble comes from the contents of the old bot, which is usually the most accurate description of the process that the business holds.
The design documents we get handed are usually accurate up to the first two or three change requests, and the changes made after that went into the workflow without an update to the document. The rules that actually run sit in If activities, an Excel config file someone edits quarterly, a Try Catch that retries a flaky ERP screen, and a hard-coded adjustment for months where the invoice run lands on a public holiday. None of that appears in the design document, and in our experience much of it only surfaces once the rebuilt process has handled a full month of real transactions. If you are being told the rebuild can be verified in a UAT window, that is the claim to press on.
June gave us one figure that gets quoted in this argument, and we want to be careful with it. UiPath surveyed nearly 600 C-suite and IT practitioners at companies with more than $1B in revenue and reported in June 2026 that 52 per cent saw hybrid workflows in day-to-day operations, meaning a combination of static repeatable processes and dynamic context-dependent ones. That survey measures how common those workflows are and says nothing about migration, so we do not stretch it into a migration finding. What we can say from our own migrations is that the context-dependent parts of a process are where a rebuilt version and the old bot produce different answers, while the static repeatable steps port across with little trouble. We would rather find those differences while the old bot is still writing to production, and that is the reason for running the two side by side.
Reading the old bot before anything gets rebuilt
The first thing we do is read the existing automation and write down what it does. For a UiPath estate that means the .xaml files, the project.json dependencies, the Orchestrator queue and asset definitions, and any Invoke Code activities holding VB or C# that never made it into a workflow diagram. Selectors tell you which application screens the process depends on and how brittle that dependency is. For Power Automate it means the flow definitions, the connector actions and expressions, and the connection references resolved at runtime.
The output is a document per process: trigger, inputs, systems touched, every decision point with its condition, every output, and every failure path. That document is the specification the parallel comparison runs against, so it is worth being pedantic about. If a decision point is missing from the document, the comparison will not test that decision point, and you will find out about it in production.
Baseline numbers come next: runs per day, items per run, average and worst-case duration, exception counts by type, and how often someone quietly fixes an exception by hand without logging it. That last number is the one nobody has, because manual fixes rarely reach a report, so we ask the people who run the process. Some of the process data may already be available. Microsoft's Power Platform 2026 release wave 1 plan records object-centric process mining reaching general availability in Power Automate Process Mining on 5 June 2026, described as a premium feature that is automatically enabled for all Power Automate Process Mining customers. That is useful to a business already holding Process Mining, and it leaves everyone else where they were.
Running the rebuild in shadow mode
The rebuilt process runs on the same trigger as the old bot, reads the same inputs, and writes nothing to production. Its outputs go to a shadow store: one record per run holding the input payload, every intermediate decision, and the final output. Where the target system offers read-only API credentials, the shadow process uses those, so an accidental write fails as a permissions error. Systems without that option get pointed at a sandbox tenant, and we accept that the sandbox reference data will drift away from production over the course of the run.
The point we raise at scoping is that parallel running creates a second copy of production data, including whatever personal information the process handles. That copy needs the same retention period, the same access list and the same masking before any field reaches a language model. UiPath's June 2026 cloud release notes record PII in-flight masking extending to files that agents download at runtime and pass to LLMs as multi-modal inputs.
There is a running cost too, because any step that uses a model to read or classify something is paid for twice while the two processes run together. Model pricing also moves during a project. Anthropic released Claude Sonnet 5 on 30 June 2026 at an introductory price of $2 per million input tokens and $10 per million output tokens, held until 31 August 2026. We are wary of budgeting a parallel window on a price with an expiry date attached, so we budget it using the price that will apply when the window closes, since introductory pricing expires part way through most runs.
Comparing the outputs, and what to do with the differences
Comparison is field by field on normalised values. Dates go to ISO 8601, currency to a fixed number of decimal places, whitespace and case are normalised on free text, and list ordering is made deterministic before the diff runs. Skip that and the first week produces hundreds of formatting differences, reviewers lose confidence in the report, and the genuine differences sit unread underneath them. The normalisation work therefore belongs before the first comparison runs, because by the second week the reviewer has already stopped opening the report.
Every genuine difference gets classified by a person into four buckets: the new process is wrong, the old bot is wrong, both outputs are acceptable, or the input was ambiguous and the process needs a rule it never had. The last two buckets produce most of the work, because they need someone with authority over the process to decide what the correct answer is, and old bots contain decisions that have not been reviewed in years. Expect that work to land on people who did not plan for it, and put their names in the schedule before the run starts.
The comparison report has to be weighted, because a process can match on most fields while getting the important ones wrong. Fields that the new process copies straight through from the input do not test anything, so we weight the fields produced by a decision and report those separately from the pass-through fields. Classification stays with a person for the whole run. An automated classifier trained on the early results tends to learn the old bot's answers and then confirm them.
Steps that read documents produce more divergence than any other kind of step, and vendor benchmarks are a weak guide to how a model will handle a particular document set. Mistral released OCR 4 on 23 June 2026 and reported that independent annotators preferred it over every leading OCR and document AI system tested, with win rates averaging 72 per cent, on a comparison Mistral ran itself. What a figure like that predicts for one client's document set cannot be read off a vendor comparison, so we test document steps against a sample of the client's own documents before the parallel run starts.
Choosing the cutover moment
We write the exit criteria before the parallel run starts. Criteria agreed part way through tend to get set at whatever the current results already show. We write them in terms of coverage: a number of consecutive business days with zero unexplained divergence on decision fields, every exception path in the process document exercised at least once, one month-end and one peak-volume day inside the window, and a sample of outputs reconciled by the process owner. We do not use elapsed time on its own as a criterion, because a process with a quarterly variant can run quietly for a fortnight and still be untested, so the window is sized to cover the full cycle of the process.
Cutover itself is a configuration change on the day. The rebuilt process starts writing to production, the old bot keeps running in shadow mode for an agreed period, and its outputs are still compared. Rollback means re-enabling the old bot's schedule, so we disable that schedule in Orchestrator and leave the definition in place. Licence and infrastructure decommissioning waits until the shadow period closes.
UiPath announced on 4 June 2026 that One NZ had cut enterprise mobile provisioning from ten days to under ten minutes using UiPath Maestro, implemented in five weeks. We read that as UiPath's own account of a customer project, and the five weeks covers the build work. We plan the parallel window as a separate line in the schedule after the build, sized by the cycle of the process being replaced. On a monthly process that has usually meant two full month-ends inside the window before the old bot's schedule is switched off.
The hardest case is the process that only runs quarterly. Sizing the window to cover a full cycle means the old bot and the rebuild run together for the better part of a year, and there is no reliable way to exercise a quarterly variant short of waiting for it to come around. An overlap of that length carries a licence cost that project budgets rarely account for, since the old bot's licences stay in place until the shadow period closes, and we price that overlap in at scoping.
If there is one thing we think the industry has wrong here, it is quoting migrations in build weeks. Build effort can be estimated from the process document with reasonable confidence. The length of the overlap is what decides the total cost and the date the old licences can be dropped, and it is the line we most often find missing from a plan we are asked to review.