{"id":6471,"date":"2026-09-01T09:12:51","date_gmt":"2026-09-01T07:12:51","guid":{"rendered":"https:\/\/storiesonboard.com\/blog\/?p=6471"},"modified":"2026-09-01T09:12:56","modified_gmt":"2026-09-01T07:12:56","slug":"story-mapping-for-enterprise-migrations","status":"publish","type":"post","link":"https:\/\/storiesonboard.com\/blog\/story-mapping-for-enterprise-migrations","title":{"rendered":"Story Mapping for Enterprise Migrations"},"content":{"rendered":"\n<p><em>How to move 50,000 users from a legacy system to a new platform without breaking their work and why the map is the only artefact that makes it possible.<\/em><\/p>\n\n\n\n<p>What we cover in this article:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Why enterprise migrations fail at the last mile<\/li>\n\n\n\n<li>The migration failure taxonomy<\/li>\n\n\n\n<li>The migration story map<\/li>\n\n\n\n<li>Building the baseline<\/li>\n\n\n\n<li>The gap analysis<\/li>\n\n\n\n<li>Migration wave planning<\/li>\n\n\n\n<li>User acceptance testing<\/li>\n\n\n\n<li>Change management<\/li>\n\n\n\n<li>How the StoriesOnBoard MCP server changes migration at scale<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><br><strong>Why enterprise migrations fail at the&nbsp;last mile<\/strong><\/h2>\n\n\n\n<p><em>Introduction \u00b7 The pattern that repeats. The cost nobody measures.<\/em><\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>The pattern is almost universal. An enterprise migration is announced. A project plan is built. A technical team executes it with discipline. The new system is faster, more secure, better architected, and cheaper to operate. The go-live date arrives. The migration is declared complete. And then the users revolt.<br><br>Not because the system is bad. Because it does not support the workflow they use every Tuesday afternoon to process regional invoices. Because it does not have the shortcut that every experienced user discovered three years ago and that nobody documented. Because the dispute process that the support team managed manually and that everyone assumed was out of scope so it turns out to be something thousands of users depend on every month.<br><br>This is what a last-mile failure looks like. The technical delivery succeeded. The user experience failed. The migration post-mortem identifies scope gaps, under-specified requirements, and insufficient change management. The real cause that the team migrated features they could see and missed workflows they could not goes unnamed. This article is about naming it. And about the practice that prevents it.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><strong>THE RUNNING EXAMPLE<\/strong><br><br>Throughout this article we follow Katalin, a Product Manager who inherited a B2B invoicing platform with 47,000 active users and a board-level commitment to migrate to a new cloud platform within twelve months. The invoicing platform had been running for six years. The original architects had left. There was no complete product documentation. The migration was originally scoped as a feature parity exercise. Story mapping revealed it was a workflow parity problem with seventeen critical gaps, three unsupported workarounds, and four workflows that should be retired rather than migrated.<\/pre>\n\n\n\n<h2 class=\"wp-block-heading\"><br><strong>The migration failure taxonomy<\/strong><\/h2>\n\n\n\n<p><em>Technical, workflow, and confidence failures. Why feature parity is the wrong goal.<\/em><\/p>\n\n\n\n<p><br>Not all enterprise migration failures are the same. Treating them as though they were by running a generic risk register and a generic change management programme is one of the primary reasons the same failures repeat across organisations and across decades of migration practice.<br><br>There are three distinct categories of migration failure. Each has different causes, different detection points, and different prevention strategies. Understanding which type you are dealing with determines what kind of planning will prevent it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Technical failures<\/h3>\n\n\n\n<p>The system does not work. Data migrations fail. Integrations break. Performance does not meet the baseline. These are the failures that governance structures are best equipped to detect: they show up in testing, in QA, in the metrics that migration programmes track as a matter of course. They are expensive to fix, but they are visible.<br><br>Technical failures are the failure mode that enterprise migration programmes are primarily designed to prevent. Risk registers. Integration testing. Data validation. Performance benchmarking. The tooling and the methodology for managing technical risk is mature and well-understood. It is not where most enterprise migrations ultimately fail.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Workflow failure<\/h3>\n\n\n\n<p>The system works perfectly. But it does not support what users actually do. This is the category that accounts for most of the last-mile failures in enterprise migrations, and it is the category that standard migration governance almost entirely fails to detect before go-live.<\/p>\n\n\n\n<p>Workflow failures happen because migration programmes map features, not journeys. They ask: does the new system have an invoicing module? Does it support payment tracking? Does it have a reporting section? The answer to all three is yes. What they do not ask is: can a user complete the end-to-end workflow they rely on to do their job, including the workarounds they have built, the edge cases they encounter, and the sequence of steps that their muscle memory has optimised over years of use?<br><br>Katalin&#8217;s team discovered this distinction when they ran their first gap analysis. The new platform had an invoicing module. It had payment tracking. It had reporting. What it did not have was any mechanism for handling invoice disputes: a gap that affected 8,000 users who processed disputed invoices monthly. And what nobody on the migration team knew was that those users had been resolving disputes manually, by emailing the support team, for three years. The workflow existed entirely outside the system. It was invisible to a feature-parity analysis. It was only visible on a story map.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Confidence failures<\/h3>\n\n\n\n<p>The system works. It supports the workflows. But users do not trust it enough to commit to it. They keep screenshots of the old system. They find workarounds that replicate old behaviours. They call the helpdesk for tasks they performed independently for years. They tell their managers the new system is not fit for purpose. Even when it is.<br><br>Confidence failures are the most expensive category because they are the hardest to detect before they have already cost the organisation significant productivity and goodwill. They are caused not by what the system does not support, but by the gap between what users expect and what they encounter. When the journey through the new system is different enough from the old one to be disorienting, even if it is objectively better, confidence fails.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><br><em>Feature parity is not workflow parity. And workflow parity is not user confidence. A migration that achieves the first without the second two will feel like a failure to the users it was supposed to serve.<\/em><\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">The 50,000 user problem<\/h3>\n\n\n\n<p>At enterprise scale, all three failure categories become harder to detect and more expensive to fix. In a small migration with fifty users, one team, a contained system tribal knowledge can be gathered informally. A handful of conversations, a walkthrough with the power users, a review session with the team lead. The gaps surface before go-live because the team is close enough to the users to see them.<br><br>At 47,000 users, tribal knowledge is not gatherable informally. Users are distributed across regions, business units, and tenure cohorts. Workflows vary by role, by location, by how long the user has been on the system. The gaps that matter most are often in the edge cases that only power users encounter and power users are, by definition, the users who have adapted most deeply to the system&#8217;s limitations. Their workflows are the hardest to see because they have been optimised over years to work around constraints that newer users never noticed.<br><br>The story map is the mechanism for making those workflows explicit at scale. Not because it replaces the conversations, but because it provides the structure within which those conversations produce something durable: a verified record of what users actually do, not what anyone believes they do.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1054\" height=\"700\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-10.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6472\" style=\"width:613px;height:auto\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-10.png 1054w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-10-300x199.png 300w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-10-768x510.png 768w\" sizes=\"auto, (max-width: 1054px) 100vw, 1054px\" \/><\/figure><\/div>\n\n\n<h2 class=\"wp-block-heading\"><br><strong>The migration story map<\/strong><\/h2>\n\n\n\n<p><em>A different kind of map. The three-level structure. The four story types unique to migration.<\/em><\/p>\n\n\n\n<p>A standard story map describes what you intend to build. A migration story map describes what users currently do, what the new system supports, and where the gap between those two things lies. It is a comparative artefact, not a design artefact. So it requires a different approach to building, verifying, and using it.<br><br>Before building one, it is worth being precise about what a story map looks like. The three-level structure is what makes it the right tool for migration analysis. Using it correctly matters.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The three-level structure<\/h3>\n\n\n\n<p>The&nbsp;<strong>top level<\/strong>&nbsp;contains the user&#8217;s high-level goals: what the user is trying to accomplish. For Katalin&#8217;s invoicing platform: Create Invoice, Send to Client, Track Payment, Manage Disputes, Report and Export. These are not features. They are goals. A user does not care about the technology. They care about getting paid, tracking what they are owed, and resolving problems when they arise.<br><br>The&nbsp;<strong>middle level<\/strong>&nbsp;contains the journey steps: the sequence of actions the user takes to achieve each goal. Under &#8220;Create Invoice,&#8221; the steps are: Add Line Items, Set Recipient, Apply Tax, Preview Invoice. This is the user&#8217;s actual experience, in sequence, from their perspective. Not what the system does internally. What the user does to move from goal to completion.<br><br>The&nbsp;<strong>bottom level<\/strong>&nbsp;contains the user stories: the specific features and behaviours that implement each journey step. Under &#8220;Add Line Items,&#8221; the stories describe what the system does when the user takes that step: validating quantities, calculating subtotals, handling line item limits. These are where the workflow detail lives and where the migration gaps become visible.<\/p>\n\n\n\n<p>For a migration, this three-level structure is what allows the comparative analysis. The goals tell you what users need to accomplish in the new system. The journey steps tell you whether the path to those goals is the same or different. The user stories tell you whether the specific behaviours users rely on are supported, missing, or requiring a workaround.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1200\" height=\"553\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/The-three-level-structure-of-a-story-map-1-1200x553.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6474\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/The-three-level-structure-of-a-story-map-1-1200x553.png 1200w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/The-three-level-structure-of-a-story-map-1-300x138.png 300w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/The-three-level-structure-of-a-story-map-1-768x354.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/The-three-level-structure-of-a-story-map-1-1536x708.png 1536w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/The-three-level-structure-of-a-story-map-1-2048x944.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/figure><\/div>\n\n\n<h3 class=\"wp-block-heading\"><br>The four migration story types<\/h3>\n\n\n\n<p>Four types of story appear on a migration map that do not appear on a greenfield map. Understanding them before the analysis begins means the team can classify findings immediately rather than debating their meaning after the fact.<\/p>\n\n\n\n<p>[ <strong>SUPPORTED<\/strong> ]<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Definition:<br><\/strong>The new system supports this workflow equivalently. The user reaches the same goal via the same or equivalent steps.<br><\/li>\n\n\n\n<li><strong>Migration Implication:&nbsp;<\/strong><br>Safe to migrate. Users who rely exclusively on supported workflows can move in Wave 1.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p>[ WORKAROUND ]<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Definition:<br><\/strong>The old system&#8217;s workaround has become a required workflow. Users depend on behaviour the system was never designed to support.<br><\/li>\n\n\n\n<li><strong>Migration Implication:&nbsp;<\/strong><br>Must become a feature in the new system before the users who depend on it can be migrated.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p>[ GAP ] <\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Definition:<br><\/strong>The workflow exists in the old system but is not supported in the new one. May be a partial implementation (Type D) or completely absent (Type A).<br><\/li>\n\n\n\n<li><strong><strong>Migration Implication:&nbsp;<\/strong><br><\/strong>Blocks migration for users who depend on this workflow until the gap is closed.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p>[ SUNSET ]<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Definition:<\/strong><br>The workflow exists in the old system but should not be migrated. The underlying business process has changed or the workflow is no longer needed.<br><\/li>\n\n\n\n<li><strong><strong>Migration Implication:&nbsp;<\/strong><br><\/strong>Communicate the retirement to any remaining users. Do not build it into the new system.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p><br><strong>Migration Baseline \u00b7 Invoicing Platform story map in StoriesOnBoard<\/strong><\/p>\n\n\n\n<p>Verified ground truth of what 47,000 users currently do, derived from the codebase, the ticket history, power user interviews, and user research. Each story has acceptance criteria derived from actual code behaviour, not from intention or memory.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1162\" height=\"1200\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Invoicing-Platform-story-map-in-StoriesOnBoard-1162x1200.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6475\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Invoicing-Platform-story-map-in-StoriesOnBoard-1162x1200.png 1162w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Invoicing-Platform-story-map-in-StoriesOnBoard-291x300.png 291w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Invoicing-Platform-story-map-in-StoriesOnBoard-768x793.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Invoicing-Platform-story-map-in-StoriesOnBoard-1488x1536.png 1488w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Invoicing-Platform-story-map-in-StoriesOnBoard.png 1730w\" sizes=\"auto, (max-width: 1162px) 100vw, 1162px\" \/><\/figure>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><a href=\"https:\/\/tomiacademy.storiesonboard.com\/storymap\/migration-baseline-invoicing-platform\">Review the Invoice Platform project on StoriesOnBoard live: <strong>CLICK HERE!<\/strong><\/a><\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Building the baseline<\/strong><\/h2>\n\n\n\n<p><em>The four evidence sources. Power user archaeology. What 47,000 users revealed.<\/em><\/p>\n\n\n\n<p>Before the first user is moved, the team needs a verified record of every user goal, every journey step, and every user story that the migration needs to support. This is the baseline. Migration is complete when the new system supports every item on the baseline map at or above the level the old system did. Not when every feature has been implemented. Not when the technical cutover is complete. When every workflow is verified.<br><br>The baseline is the migration&#8217;s definition of done. Everything else (the gap analysis, the wave planning, the UAT, the change management programme) derives from it. The quality of the baseline determines the quality of everything that follows.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The four evidence sources<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>The Codebase<\/strong><br>The codebase&nbsp;is the ground truth. It does not lie and does not remember things incorrectly. For Katalin&#8217;s team, reading the invoicing service with a product lens meant looking at route handlers and asking: what user action does each of these correspond to? The POST to \/invoices corresponds to &#8220;Create Invoice.&#8221; The GET to \/invoices\/:id\/status corresponds to &#8220;View Payment Status.&#8221; And there was also a POST to \/disputes: a route that existed in the codebase but that no one on the team could connect to any user-facing feature. This became one of the most important findings of the entire exercise.<br><br><\/li>\n\n\n\n<li><strong>The existing tickets<\/strong><br>The existing tickets&nbsp;contain rationale that often does not exist anywhere else. Katalin&#8217;s team found three things in the ticket history that changed the mapping exercise: a 2021 ticket where the dispute endpoint was added but closed as &#8220;incomplete&#8221; because the UI work was never finished; a 2023 ticket where a payment status bug was fixed with a workaround, not a structural solution; and a 2020 ticket explicitly marking recurring invoices as out of scope. Three decisions that shaped six years of system behaviour, visible only in the ticket archive.<br><br><\/li>\n\n\n\n<li><strong>The long-tenured team member<\/strong><br>The long-tenured team member&nbsp;carries context that has never been written down. In Katalin&#8217;s team, this was Andras, the QA engineer who had been on the system for four years. The mistake most teams make is asking Andras to &#8220;explain the system.&#8221; The better approach is structured: take the goals and journey steps drafted from the codebase and ask Andras to verify, correct, and annotate each one. Andras told the team something nobody else knew: that the payment status endpoint returned stale data for bank transfer payments, because the reconciliation job ran nightly rather than in real time. This had been causing intermittent customer queries for three years. It was not in the code comments. It was not in the tickets. It was in one person&#8217;s memory and the mapping exercise extracted it.<br><br><\/li>\n\n\n\n<li><strong>The users themselves<\/strong><br>The users themselves&nbsp;reveal the gap between the journey the team designed and the journey users actually take. Katalin reviewed six months of support tickets before the mapping session and found two patterns that changed the map. First, a recurring question about handling disputed invoices. Customers had no way to do this in the system, so they emailed support manually for every dispute. Second, a pattern of customers creating a new invoice to correct a sent invoice they had made an error on, because there was no way to edit a sent invoice. Twelve thousand users were doing this every month. Nobody on the product team knew.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">The power user problem<\/h3>\n\n\n\n<p>Power users are both the most important source of baseline evidence and the most likely to be missed. They have adapted to the system so deeply that they no longer describe their workarounds as workarounds. They describe them as &#8220;how the system works.&#8221; When asked whether they can edit a sent invoice, a power user might say yes, because they have been creating correction invoices for so long that the workaround feels like a feature.<br><br>Extracting implicit workflows from power users requires structured sessions, not open conversations. Take the drafted map into the session. Walk through each journey step. Ask: &#8220;When you do this step, is there anything you do that is not described here?&#8221; Ask: &#8220;What do you do when this step fails or when you make an error?&#8221; Ask: &#8220;What do you do that a new user probably does not know to do?&#8221; These questions surface the optimisations, the shortcuts, and the workarounds that a general walkthrough never reaches.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><strong>SCOPING THE BASELINE EXERCISE<\/strong><br><br>Do not attempt to map the entire system at once. Scope to the product area directly relevant to the current migration commitment. Katalin's team scoped to the payments and disputes domain and not the full invoicing system, not the reporting section. The first scoped baseline took four days. The second domain took two. By the third, the team had a repeatable process and the confidence to move quickly without losing accuracy.<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">What the baseline revealed<\/h3>\n\n\n\n<p>After four days of mapping work: one day of preparation, one day of session, one day of engineering review, and one day of power user verification, Katalin\u2019s team had their first complete view of what 47,000 users actually did in the invoicing platform.<br><br>Five high-level goals. Fourteen journey steps. Sixteen user stories with acceptance criteria derived from actual code behaviour. And three things they had not expected: a dispute endpoint that existed in the backend but had never been connected to a user interface; a bank transfer reconciliation process with a known data quality issue; and a workaround (creating correction invoices) that 12,000 users relied on monthly and that nobody on the product team had known about.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><br><strong>The gap analysis<\/strong><\/h2>\n\n\n\n<p><em>Four gap types. The seventeen gaps. The finding that changed the plan before the sprint started.<\/em><\/p>\n\n\n\n<p>With the baseline established, the migration team maps each item against the new system. Supported, Gap, Workaround, or Sunset. This comparative analysis produces the migration&#8217;s actual risk register: not a list of technical risks, but a list of workflow risks ranked by user impact. It is the document that changes the project plan, adjusts the go-live timeline, and realigns stakeholder expectations before a single user is moved.<\/p>\n\n\n\n<p><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The gap classification for migration<\/h3>\n\n\n\n<p>Four gap types appear in a migration analysis. Each requires a different response and has a different impact on the migration plan.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Supported workflows<\/strong>:<br>Supported workflows&nbsp;are straightforward: the new system handles this workflow equivalently. The user reaches the same goal via the same or equivalent steps. These stories are coloured Green on the gap analysis map. Users who rely exclusively on supported workflows are candidates for Wave 1 migration.<br><br><\/li>\n\n\n\n<li><strong>Workaround workflows<\/strong>:<br>Workaround workflows&nbsp;are the most dangerous category because they are the hardest to see. The old system&#8217;s workaround has become a required workflow \u2014 users depend on behaviour the system was never designed to support, and they have come to rely on it so completely that removing it without replacement will break their daily work. For Katalin&#8217;s team, the correction invoice workaround was the critical finding here. Twelve thousand users created a new invoice every time they needed to correct an error on a sent invoice.<br><br>The new platform had no equivalent mechanism and the workaround could not be replicated because the new system&#8217;s data model did not support it. A new &#8220;edit sent invoice&#8221; feature needed to be built before those users could be migrated.<br><br><\/li>\n\n\n\n<li><strong>Gap workflows<\/strong>:<br>Gap workflows&nbsp;split into two types. Type D gaps are where code exists in the legacy system but was never connected to a user interface. They are the most technically misleading because they look like existing functionality but are not. Katalin&#8217;s dispute endpoints were a Type D gap. The backend code existed. No user had ever accessed it through the UI. Building the new dispute feature on top of the existing partial implementation would have meant inheriting all of its incompleteness. The correct decision was to discard the legacy code and build the dispute feature from specification in the new platform. Type A gaps (where the feature was simply never built) are cleaner: they require net-new development with no legacy code to untangle.<br><br><\/li>\n\n\n\n<li><strong>Sunset workflows<\/strong>:<br>Sunset workflows&nbsp;exist in the old system but should not follow the users to the new one. Katalin&#8217;s CSV export feature was a sunset candidate: it had been built for integration with a legacy accounting system that was itself being replaced by a direct API integration in the new platform. Migrating the CSV export would have been technically straightforward and operationally pointless.<\/li>\n<\/ol>\n\n\n\n<p><br><strong>Migration Gap Analysis \u00b7 Invoicing Platform story map in StoriesOnBoard<\/strong><br><br>Example for each workflow type present in the Migration Gap Analysis story map.<\/p>\n\n\n\n<figure class=\"wp-block-gallery has-nested-images columns-default is-cropped wp-block-gallery-1 is-layout-flex wp-block-gallery-is-layout-flex\">\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1140\" height=\"1200\" data-id=\"6478\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Gap-Analysis-map-in-StoriesOnBoard-1-1140x1200.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6478\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Gap-Analysis-map-in-StoriesOnBoard-1-1140x1200.png 1140w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Gap-Analysis-map-in-StoriesOnBoard-1-285x300.png 285w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Gap-Analysis-map-in-StoriesOnBoard-1-768x809.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Gap-Analysis-map-in-StoriesOnBoard-1-1459x1536.png 1459w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Gap-Analysis-map-in-StoriesOnBoard-1.png 1702w\" sizes=\"auto, (max-width: 1140px) 100vw, 1140px\" \/><\/figure>\n<\/figure>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><a href=\"https:\/\/tomiacademy.storiesonboard.com\/storymap\/migration-gap-analysis-invoicing-platform\">Review the Migration Gap Analysis map on StoriesOnBoard live: <strong>CLICK HERE!<\/strong><\/a><\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">The seventeen gaps<\/h3>\n\n\n\n<p>Katalin&#8217;s gap analysis produced seventeen gaps across the payments and disputes domain. This is the number that changed the project plan.<br><br>The original migration scope was built on a feature parity assumption: the new platform had an invoicing module, a payment module, and a reporting module, therefore it supported what users needed. The gap analysis showed that feature parity covered approximately 60% of the workflows that mattered to users. The remaining 40% were either gaps that needed to be built, workarounds that needed to be replaced, or sunset candidates that needed to be communicated and retired.<br><br>More importantly, the gap analysis showed which gaps affected which users. The dispute gap affected 8,000 users. Not the majority, but a concentration that included the company&#8217;s largest enterprise accounts. The correction invoice workaround affected 12,000 users across every business segment. Migrating either group before the gaps were addressed would have produced exactly the kind of last-mile failure that enterprise migrations are infamous for.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><strong>THE FINDING THAT CHANGED THE Q3 PLAN<\/strong><br><br>The most important finding of the gap analysis was the Type D dispute gap. The backend code that existed but had never been shipped as a user-facing feature. The original migration plan assumed the dispute resolution feature was a UI project: the backend existed, the team just needed to build the frontend. The gap analysis revealed that the backend was not production-ready. It had been written as a partial implementation years ago, never finished, never tested at scale, never integrated with the payment reconciliation system.\u2028\u2028<br><br><strong>This discovery happened in week one of the mapping exercise.<\/strong>&nbsp;Not in week three of the sprint. Not in QA. Not in production. The scope correction (extending the estimate, adjusting the release scope, communicating the change to stakeholders) happened as a planning decision rather than a crisis. That is the return on investment of the gap analysis, expressed in its simplest form.<\/pre>\n\n\n\n<h3 class=\"wp-block-heading\"><br>Prioritizing gaps by user impact, not technical effort<\/h3>\n\n\n\n<p>The natural instinct when a gap analysis produces seventeen gaps is to prioritise by development effort: close the easy gaps first, build momentum, then tackle the complex ones. This is the wrong approach for a migration.<br><br>A technically simple gap that affects 40,000 users on their most frequent workflow is more dangerous to migration success than a complex gap that affects 200 users on a quarterly process. Migration prioritisation must be weighted by user impact. The number of users affected, the frequency with which they encounter the gap, and the consequence to their work if it is not closed before their wave migration date.<br><br>For Katalin&#8217;s team, this meant the correction invoice workaround (a mid-complexity development task) was prioritised above several technically simpler gaps because it affected 12,000 users on a weekly workflow. The dispute resolution gap was prioritised above the reporting gaps because the users it affected were the company&#8217;s largest accounts, where a failed migration would have had direct commercial consequences.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1200\" height=\"655\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-12-1200x655.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6480\" style=\"width:634px;height:auto\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-12-1200x655.png 1200w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-12-300x164.png 300w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-12-768x419.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-12-1536x838.png 1536w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-12-2048x1117.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/figure><\/div>\n\n\n<h2 class=\"wp-block-heading\"><br><strong>The migration wave planning<\/strong><\/h2>\n\n\n\n<p><em>Journey-complete, not cohort-complete. How to draw the wave boundary on the map.<\/em><\/p>\n\n\n\n<p>Most enterprise migration wave plans are defined by the wrong criteria. Geography is the most common ( such as migrate Western Europe in Q2, Asia-Pacific in Q3, North America in Q4. Business unit is the second most common) migrate Finance first, then Operations, then Sales. These criteria are organisationally convenient. They are not user-experience criteria. And they produce waves that are internally incoherent from a workflow perspective.<br><br>A wave defined by geography will contain users with radically different workflow profiles. Some of those users rely exclusively on supported workflows and are ready to migrate immediately. Others rely on the correction invoice workaround that has not yet been replaced. Others are among the 8,000 users who process disputes monthly and cannot migrate until the dispute feature passes UAT. Migrating a geographic cohort as a unit means migrating users before their specific workflows are supported which is precisely the condition that produces last-mile failures.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Journey-complete wave planning<\/h3>\n\n\n\n<p>The alternative is to define migration waves by workflow readiness, not by organisational structure. Wave 1 includes users whose workflows are entirely supported in the new system: no gaps, no workarounds that have not been replaced, no relearning required beyond the interface change. Wave 2 includes users whose workflows involve Type 1 relearning challenges: the new system supports their goals, but via a different path, and they need guided transition support before migration. Wave 3 includes users who depended on Type 2 gaps that have now been built and verified.<\/p>\n\n\n\n<p>The wave boundary is drawn on the map as a release slice, a horizontal line that separates what is supported from what is not. Everything above the line can be migrated. Everything below it cannot \u2014 yet. The line is drawn by journey step completeness, not by estimate or by organisational unit.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1200\" height=\"683\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Wave-plan-overview-1200x683.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6481\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Wave-plan-overview-1200x683.png 1200w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Wave-plan-overview-300x171.png 300w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Wave-plan-overview-768x437.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Wave-plan-overview-1536x875.png 1536w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Wave-plan-overview-2048x1166.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/figure><\/div>\n\n\n<p><br><strong>Migration Wave Plan \u00b7 Invoicing Platform story map in StoriesOnBoard<\/strong><\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1200\" height=\"687\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Wave-Plan-story-map-in-StoriesOnBoard-1200x687.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6482\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Wave-Plan-story-map-in-StoriesOnBoard-1200x687.png 1200w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Wave-Plan-story-map-in-StoriesOnBoard-300x172.png 300w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Wave-Plan-story-map-in-StoriesOnBoard-768x440.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Wave-Plan-story-map-in-StoriesOnBoard-1536x880.png 1536w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-Wave-Plan-story-map-in-StoriesOnBoard-2048x1173.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/figure><\/div>\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><a href=\"https:\/\/tomiacademy.storiesonboard.com\/storymap\/migration-wave-plan-invoicing-platform\">Review the Migration Wave Plan map on StoriesOnBoard live: <strong>CLICK HERE!<\/strong><\/a><\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Communicating wave plans to stakeholders<\/h3>\n\n\n\n<p>Wave plans defined by workflow readiness are more complex to communicate than geography-based plans. But they are also more defensible. When a stakeholder asks why Western European users are being split across three different waves, the answer is visible on the map: some of them rely on workflows that are already supported, some rely on workflows that need relearning support, and some rely on workflows that have not yet been built. The map makes the rationale concrete rather than abstract.<br><br>The critical communication shift is from &#8220;we are migrating this group in Q2&#8221; to &#8220;we are migrating users whose workflows fall above this line in Q2, and here is what the line means for each user group.&#8221; The first statement describes a schedule. The second describes a commitment: a guarantee that no user will be migrated before the system supports their work.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><br><em>Journey-complete wave planning is not a commitment to perfection. It is a commitment to not breaking anyone&#8217;s work in the name of a schedule.<\/em><\/p>\n<\/blockquote>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1014\" height=\"630\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-13.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6483\" style=\"width:530px;height:auto\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-13.png 1014w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-13-300x186.png 300w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-13-768x477.png 768w\" sizes=\"auto, (max-width: 1014px) 100vw, 1014px\" \/><\/figure><\/div>\n\n\n<h2 class=\"wp-block-heading\"><br><strong>User acceptance testing<\/strong><\/h2>\n\n\n\n<p><em>Workflow parity, not feature parity. UAT scripts from the map. Power user UAT.<\/em><\/p>\n\n\n\n<p>Traditional UAT verifies that the new system has the features the specification called for. Migration UAT should verify that the new system supports the workflows the baseline map defined. These are different tests with different pass criteria and different failure modes, and confusing them is one of the primary reasons UAT passes and users still revolt at go-live.<br><br>A feature test asks: does the invoicing module exist? Does it accept line items? Does it calculate totals? These questions can all be answered yes while the system still fails to support the workflow that a power user with eight years of experience relies on every Tuesday afternoon.<br><br>A workflow test asks: can a user accomplish this specific goal via this specific journey step with these specific behaviours and these specific edge cases handled? That question requires the baseline map to answer because the baseline map is where the specific journey steps, the specific behaviours, and the specific edge cases were documented.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><br>UAT scripts from the map<\/h3>\n\n\n\n<p>The migration acceptance criterion for each user story defines what workflow parity looks like in the new platform. Not &#8220;the feature exists&#8221; but &#8220;a user can accomplish this specific goal via this specific journey step with these specific inputs, outputs, and edge cases.&#8221;<br><br>Each journey step on the baseline map produces a test scenario. Each user story produces a test case. Each acceptance criterion produces a pass\/fail condition. The map is the test plan. The team does not write a separate UAT document. They derive the UAT scripts from the map, which means the UAT is automatically complete when the map is complete and automatically current when the map is current.<\/p>\n\n\n\n<p><br><strong>Migration UAT \u00b7 Invoicing Platform story map in StoriesOnBoard<\/strong><\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"847\" height=\"1200\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-UAT-story-map-in-StoriesOnBoard-1-847x1200.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6487\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-UAT-story-map-in-StoriesOnBoard-1-847x1200.png 847w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-UAT-story-map-in-StoriesOnBoard-1-212x300.png 212w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-UAT-story-map-in-StoriesOnBoard-1-768x1088.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-UAT-story-map-in-StoriesOnBoard-1-1084x1536.png 1084w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/Migration-UAT-story-map-in-StoriesOnBoard-1.png 1338w\" sizes=\"auto, (max-width: 847px) 100vw, 847px\" \/><\/figure><\/div>\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><a href=\"https:\/\/tomiacademy.storiesonboard.com\/storymap\/migration-uat-invoicing-platform\">Review the Migration UAT map on StoriesOnBoard live: <strong>CLICK HERE!<\/strong><\/a><\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">What the UAT map shows<\/h3>\n\n\n\n<p>Map 4 shows the UAT status across all sixteen baseline stories plus the gap-closure test cases. Green stories have passed UAT: the power user group confirmed that the new platform supports the workflow equivalently. Yellow stories are in progress: the bank transfer reconciliation relearning scenario, where eight of twenty power users had completed the walkthrough and five were still in progress. Red stories are blocked: the dispute initiation and dispute resolution test cases cannot begin until the features are built.<br><br>This is the information a steering committee needs to make a wave readiness decision. Not &#8220;are we on track&#8221;  but which specific workflows are verified, which are in progress, and which are blocked, and what does that mean for which users can be safely migrated and which cannot.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Power user UAT<\/h3>\n\n\n\n<p>Power users should run the UAT for the workflows they own. Not because they are the most rigorous testers (they are not) but because they are the most likely to discover the implicit behaviours that the formal test scripts did not capture. A power user running the &#8220;create invoice&#8221; UAT scenario will naturally attempt their optimised version of the workflow, including the shortcuts and edge case sequences that the script did not describe. When those sequences produce unexpected results, the discovery happens in UAT rather than in production.<br><br>Katalin&#8217;s team assigned each power user to the UAT scenarios for the journey steps they used most frequently. The bank transfer reconciliation scenario was assigned to the three users who processed the highest volume of bank transfer payments. The correction invoice scenario was assigned to the five users who created the most correction invoices per month. The dispute scenarios were assigned to the team leads who managed the most complex dispute cases.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><br><strong>Change management<\/strong><\/h2>\n\n\n\n<p><em>The change journey as a product. Role-specific journeys. Measuring adoption through step completion.<\/em><\/p>\n\n\n\n<p>Enterprise change management programmes typically consist of three things: training, communication, and support. These address the surface of the change. The deeper challenge is the user&#8217;s journey through the change itself from &#8220;I hear we are getting a new system&#8221; through &#8220;I understand what this means for my daily work&#8221; through &#8220;I can do my job in the new system as well as I could in the old one.&#8221; That journey is a product. It can be designed. It can be mapped. And it can fail in exactly the same ways that a product journey fails: through gaps, through workarounds, and through a mismatch between what the team thought users needed and what users actually experienced.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">The change journey map<\/h3>\n\n\n\n<p>Map 5 is different from the other four. It does not describe what the invoicing system does. It describes what users experience as they move through the change. The high-level goals are the stages of adoption: Awareness, Understanding, Confidence, and Full Adoption. The journey steps are the specific moments in the change experience: receiving the migration announcement, attending the Q&amp;A session, completing role-specific training, practising in the sandbox, confirming readiness, completing the first real task in the new platform. The user stories are the touchpoints: the specific communications, training sessions, peer conversations, and support interactions that move users from one stage to the next.<\/p>\n\n\n\n<p><strong>Change Journey Map \u00b7 Invoicing Platform story map in StoriesOnBoard<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1200\" height=\"353\" src=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-14-1200x353.png\" alt=\"%Start story mapping today%\" class=\"wp-image-6488\" title=\"\" srcset=\"https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-14-1200x353.png 1200w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-14-300x88.png 300w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-14-768x226.png 768w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-14-1536x452.png 1536w, https:\/\/storiesonboard.com\/blog\/wp-content\/uploads\/2026\/08\/image-14-2048x602.png 2048w\" sizes=\"auto, (max-width: 1200px) 100vw, 1200px\" \/><\/figure>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p><a href=\"https:\/\/tomiacademy.storiesonboard.com\/storymap\/change-journey-map-invoicing-platform\">Review the Change Journey map on StoriesOnBoard live: <strong>CLICK HERE!<\/strong><\/a><\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">The four adoption stages<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Awareness<\/strong><br>Awareness&nbsp;is the stage where users know change is coming. They are not yet anxious. They simply know. The journey step is receiving the migration announcement with enough clarity and enough notice to begin preparing. The failure mode at this stage is communication that is either too vague to be actionable or too technical to be understood by non-technical users.<br><br><\/li>\n\n\n\n<li><strong>Understanding<\/strong><br>Understanding&nbsp;is the stage where users know specifically what is changing for their role. Not for users in general but for them. The journey steps are receiving a role-specific change impact summary and exploring the new platform&#8217;s features before being required to use them. The failure mode at this stage is generic communication that describes the system change without connecting it to the specific workflows each user relies on.<br><br><\/li>\n\n\n\n<li><strong>Confidence<\/strong><br>Confidence&nbsp;is the stage where users feel capable of doing their job in the new platform. They have completed training. They have practised in the sandbox. They have had their questions answered by the product team, by a peer champion, by the documentation. The failure mode at this stage is training that covers features rather than workflows, and sandbox access without realistic data or realistic scenarios.<br><br><\/li>\n\n\n\n<li><strong>Full Adoption<\/strong><br>Full Adoption&nbsp;is the stage where users are working independently in the new platform and no longer need support scaffolding. The journey steps are completing the first real task on migration day, accessing support when needed in the first two weeks, and receiving confirmation that the legacy system has been decommissioned. The failure mode at this stage is abandoning users immediately after migration day. Even before they have had the chance to encounter the edge cases that training did not cover.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Role-specific change journeys<\/h3>\n\n\n\n<p>At 47,000 users, different user roles experience the change differently. A power user who has been on the old system for eight years has a different change journey than a new hire who never used it. The power user&#8217;s challenge is unlearning: releasing the muscle memory and the optimised workflows they have built over years. The new hire&#8217;s challenge is learning: building familiarity with a system they have no reference point for.<br><br>Katalin&#8217;s team identified three user roles with significantly different change journeys: standard invoice creators, who had the simplest transition; accounts managers, who processed the highest volume and whose reconciliation workflows were changing most significantly; and dispute handlers, who could not be migrated until Wave 3 and who needed a different communication approach to manage the extended timeline without losing confidence in the migration programme.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Measuring adoption through journey step completion<\/h3>\n\n\n\n<p>The change journey map becomes the adoption measurement framework. Instead of measuring &#8220;percentage of users trained&#8221; (a metric that captures exposure but not capability) the team measures the percentage of users who have completed each journey step in the change map. Percentage who received and opened the announcement. Percentage who attended or watched the Q&amp;A recording. Percentage who completed the role-specific training. Percentage who confirmed readiness before their wave migration date.<br><br>These are leading indicators of adoption success and not whether users have been exposed to the change, but whether they have progressed through the journey it requires. And they are measurable before go-live, which means the team can identify and intervene with lagging users before migration day rather than after the helpdesk volume spike tells them something went wrong.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><br><strong>How the MCP server changes migration at scale<\/strong><\/h2>\n\n\n\n<p><em>AI-generated AC. Untranslatable workflow identification. Wave readiness reporting.<\/em><\/p>\n\n\n\n<p>A 47,000-user migration produces a baseline map with hundreds of user stories, dozens of gap types, wave plans that need to stay current as gaps are closed, UAT scripts that need to reflect the map&#8217;s current state, and change journey tracking that needs to update as users progress through adoption. At this scale, keeping the map current manually is not sustainable. The people who would do it are the people the migration cannot afford to distract from planning, decision-making, and stakeholder management.<br><br>The <a href=\"https:\/\/docs.storiesonboard.com\/en\/articles\/14625286-storiesonboard-model-context-protocol-mcp-server-overview\"><strong>StoriesOnBoard MCP server<\/strong><\/a> changes the economics of migration map maintenance by making it possible for AI agents to perform the systematic, high-volume tasks (drafting, updating, checking, reporting) that consume the team&#8217;s time without consuming their judgment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">AI-generated migration acceptance criteria<\/h3>\n\n\n\n<p>The baseline map contains sixteen user stories. The gap analysis adds gap-closure stories for each of the seventeen gaps. The UAT map needs a migration acceptance criterion for every story on the baseline. That is forty-plus acceptance criteria, each of which needs to be specific to the workflow it tests, consistent with the team&#8217;s format, and current with the latest understanding of what the new system supports.<br><br>An agent connected to the baseline map via the MCP server can read every story, read the adjacent stories that establish the team&#8217;s acceptance criterion format and conventions, and generate migration acceptance criteria for the entire set: consistently formatted, covering the edge cases documented in each story, and updated automatically when a story is modified. What previously took a BA team a week to produce becomes an agent task that takes hours and a review session that takes an afternoon.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Untranslatable workflow identification<\/h3>\n\n\n\n<p>Some workflow gaps are not gaps in the traditional sense. They are architectural incompatibilities. The new platform&#8217;s data model, security model, or integration architecture makes it impossible to support a legacy workflow without a structural change that exceeds the migration budget or timeline. These are the gaps that need to be identified early, surfaced to decision-makers, and resolved as explicit design decisions rather than discovered mid-sprint as implementation blockers.<br><br>An agent connected to the baseline map and to the new platform&#8217;s capability documentation can flag user stories where the gap between the old workflow and the new system&#8217;s support for it is structural rather than cosmetic. It cannot make the architectural judgment. That requires human expertise, but it can surface the candidates, describe the nature of the incompatibility, and present the options. The judgment call happens in a meeting. The preparation for that meeting happens in minutes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">User-facing change impact assessments<\/h3>\n\n\n\n<p>The change journey map requires role-specific change impact summaries: one-page documents that tell each user role exactly what is changing for them, what is staying the same, and what they need to do before their migration date. For a 47,000-user migration with three significant user roles, this is three documents. For a migration with ten user roles across regional business units, this is potentially dozens of documents, each of which needs to be accurate, current, and specific.<br><br>An agent connected to the gap analysis map and the change journey map via the MCP server can generate role-specific change impact assessments automatically. Grouped by the journey steps that each role relies on, classified by gap type, and formatted for non-technical readers. When the gap analysis is updated (when a gap is closed, when a workaround is resolved, when a sunset decision is made) the change impact assessment can be regenerated automatically to reflect the current state.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Wave readiness reporting<\/h3>\n\n\n\n<p>The steering committee needs a weekly answer to the same question: which user groups are ready to migrate and which are not? In a geography-based migration programme, this question is answered by a Gantt chart. In a workflow-readiness-based programme, it requires knowing the current state of every gap, every UAT scenario, and every change journey step completion rate, and translating that information into a wave readiness assessment for each user segment.<br><br>An agent connected to the UAT map and the wave plan map via the MCP server can read the current status of every story, identify which wave boundaries have been cleared, flag which gaps remain open and for which user segments, and generate a wave readiness report that gives the steering committee a real-time view of migration progress and not in terms of tasks completed, but in terms of users who are safe to move and users who are not.<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\"><strong>WHAT THIS LOOKS LIKE IN PRACTICE<\/strong><br><br>For Katalin's migration, the MCP-connected workflow would have changed three specific workstreams. The acceptance criteria generation that took the BA team a week would have been an agent task followed by an afternoon review session. The wave readiness reporting that consumed two hours of the programme manager's time every Friday would have been an agent-generated report reviewed in twenty minutes. And the change impact assessments that were written once and never updated would have been living documents, regenerated each time the gap analysis changed.\u2028\u2028<br><br>The judgment calls (which gaps to prioritise, which users to move in which wave, how to communicate a delayed migration to enterprise accounts) remained with the team. The preparation, the maintenance, and the reporting that supported those judgment calls moved to the agent.&nbsp;<br><br><strong>That is the division of labour that makes a 47,000-user migration manageable without a team of forty.<\/strong><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\"><br><strong>Workflow parity is the success criterion nobody measures<\/strong><\/h2>\n\n\n\n<p>Enterprise migrations will continue to fail at the last mile as long as success is defined by technical delivery rather than by user workflow continuity. The governance structures, the risk registers, the steering committees, and the programme plans that large organisations deploy to manage migration risk are excellent at tracking whether the system works. They are almost entirely blind to whether the system supports what users do.<br><br>Katalin&#8217;s migration delivered on time and within budget. Not because the development went perfectly, it never does. But because the major scope surprises were discovered in week one of the mapping exercise rather than in week three of the sprint, in QA rather than in production, in a planning conversation rather than in a crisis. The dispute backend was found to be incomplete before the sprint that would have built on top of it began. The correction invoice workaround was identified before 12,000 users were moved to a platform that could not replace it. The bank transfer reconciliation relearning gap was documented before users encountered it without preparation.<br><br>Each of those discoveries was made by the story map. Not by a risk register. Not by a technical review. By a structured record of what users actually do derived from the code, the tickets, the long-tenured engineer, and the users themselves, it held up against what the new system actually supports, and the gaps made visible before anyone was asked to cross them.<br><br>The baseline map is the migration&#8217;s definition of done. The gap analysis is the migration&#8217;s actual project plan. The wave plan is a commitment not a schedule, but a guarantee that no user will be migrated before the system supports their work. The UAT is the verification that the commitment has been kept. The change journey map is the design of the human experience of the change itself, treated with the same rigour as the technical migration.<br><br>Fifty thousand users do not experience a migration as a technical event. They experience it as a change to how they accomplish goals that matter to them. Story mapping keeps that experience at the centre of the migration programme, and the StoriesOnBoard MCP server keeps it sustainable at the scale where it matters most.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link wp-element-button\" href=\"https:\/\/storiesonboard.com\/\">Start your migration on StoriesOnBoard<\/a><\/div>\n<\/div>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p><strong>Learn more about:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/storiesonboard.com\/blog\/how-to-actually-deploy-claude-in-your-product-development-workflow\">How to Actually Deploy Claude in Your Product Development Workflow<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/docs.storiesonboard.com\/en\/articles\/14625286-storiesonboard-model-context-protocol-mcp-server-overview\">How StoriesOnBoard MCP server works<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/docs.storiesonboard.com\/en\/articles\/14497894-how-to-add-storiesonboard-mcp-server-to-claude-desktop\">How to connect Claude to your story map on StoriesOnBoard<\/a><\/li>\n<\/ul>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>How to move 50,000 users from a legacy system to a new platform without breaking their work and why the map is the only artefact that makes it possible. What &#8230; <a title=\"Story Mapping for Enterprise Migrations\" class=\"read-more\" href=\"https:\/\/storiesonboard.com\/blog\/story-mapping-for-enterprise-migrations\" aria-label=\"Read more about Story Mapping for Enterprise Migrations\">Read more<\/a><\/p>\n","protected":false},"author":14,"featured_media":6495,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"image","meta":{"footnotes":""},"categories":[7],"tags":[1025,1021,1024,862,871,935,877],"class_list":["post-6471","post","type-post","status-publish","format-image","has-post-thumbnail","hentry","category-story-mapping","tag-enterprise-migration","tag-enterprise","tag-mcp","tag-product-discovery","tag-product-management","tag-product-roadmap","tag-story-mapping","post_format-post-format-image","resize-featured-image"],"_links":{"self":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts\/6471","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/users\/14"}],"replies":[{"embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/comments?post=6471"}],"version-history":[{"count":8,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts\/6471\/revisions"}],"predecessor-version":[{"id":6533,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/posts\/6471\/revisions\/6533"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/media\/6495"}],"wp:attachment":[{"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/media?parent=6471"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/categories?post=6471"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/storiesonboard.com\/blog\/wp-json\/wp\/v2\/tags?post=6471"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}