How to Identify the First Microservice to Extract

The first microservice to extract from a monolith is not just the first technical deliverable. It's the foundation of your team's extraction competency, the proof of your operational platform, and the pattern every later extraction will follow. Choose well and the programme builds momentum. Choose a highly coupled service, an unstable domain boundary, or too large a scope, and the team spends months on a hard extraction that delivers limited value while organisational patience wears thin.

AI tools have compressed candidate analysis from weeks to days without cutting corners on rigour. CAST Imaging scores coupling for every module in hours. CodeScene reads two years of git history in minutes. The judgement still needs a human. The evidence behind it just got a lot faster to gather.

Why the First Service Extraction Is the Most Consequential Decision You Will Make

Most engineering leaders treat first-service selection as a technical detail to resolve quickly so the "real work" can begin. That framing is wrong. Extracting microservices from monolith systems the right way means the first extraction is not the preamble to the migration. It's the migration in miniature.

Every pattern set in the first extraction gets copied and scaled across every extraction after it, including:

• Test strategy and coverage standard
• Documentation format and depth
• Deployment pipeline and rollback process
• Monitoring and alerting configuration
• Code review standard
• Parallel running methodology

A first extraction done well creates a replicable pattern. A first extraction done badly creates a replicable disaster.

The Five Functions of the First Extraction

The first service you extract does more than deliver one working microservice. It performs five distinct jobs at once.

Pattern Establishment

The first extraction is the template: test strategy, documentation format, deployment pipeline, monitoring configuration, code review standard, runbook format, all scaled to every subsequent service. Get it wrong and fifteen later extractions inherit the same flaws, and fixing a template mid-programme is expensive and demoralising.

Team Capability Building

The team learns the extraction process on the first service, and every later service moves faster as proficiency builds with the pattern, the tools, and the AI toolchain. If the first service is too hard, the learning curve stretches out and confidence never quite settles.

Operational Platform Validation

The first extraction proves the CI/CD pipeline, distributed tracing, API gateway routing, and monitoring all work as designed. A complex first service can fail for platform reasons that a simpler service would have caught earlier.

Executive Confidence

The first extraction is the evidence that the programme delivers on its business case. A first extraction with only technical improvement and no visible business outcome starts the stakeholder confidence slide that eventually threatens funding.

AI toolchain Calibration

The first extraction is where AI tools get configured and validated for the specific codebase. Diffblue Cover test quality, Copilot suggestion relevance, and Mintlify documentation accuracy all get tuned here. Catching configuration issues on the third or fourth service means the earlier ones ran on lower-quality AI assistance.

The Three Sequencing Mistakes That Fail First Extractions

Three patterns show up again and again when a first extraction goes wrong, well before structural coupling analysis even gets a chance to flag them, and AI analysis can catch two of them before a single line of code gets written.

Starting With The Highest-Business-Value Service

The payment engine, the core order system, and the main product catalogue get chosen first because it will demonstrate the most impact. These are also the most tightly coupled, most complex, most business-critical components. A problem in the first extraction disrupts production for the most important function, and the team learns extraction on the hardest problem in the system. CAST Imaging's coupling score for high-value services almost always shows high coupling, flagging the risk before anyone commits.

Starting With The "Architecturally Cleanest" Service

Engineers pick something technically interesting to build instead: a new event-driven feature, a GraphQL federation layer. These are often greenfield builds rather than extractions from the monolith, so the team learns to build new services but not to extract existing ones, which is the actual skill the programme needs. AI can only partially catch this one; domain expert input is still needed to confirm what counts as a real extraction.

Starting Too Large

A service spanning three or four business capabilities gets chosen to "show significant progress quickly," and the scope exceeds what fits in 10 to 12 weeks. The extraction stretches past 20 weeks, first business value slips past the 90-day threshold, and patience runs out before the first milestone lands. CAST Imaging scope analysis catches this overreach before programme start, not after.

If your organisation is early in this journey, it helps to bring in a partner offering software product modernization services before the first architect meeting, so sequencing decisions get made with the full evidence base rather than gut instinct.

The Five-Day AI-Assisted Candidate Analysis Process

Traditional first-service candidate analysis required 3 to 4 weeks of senior engineer time spent reading code, tracking down integration owners, and running manual coupling analysis by hand. AI tools compress this dependency analysis to 5 business days without reducing coverage depth. CAST Imaging surfaces coupling patterns manual review misses, CodeScene reveals temporal dependencies invisible to structural analysis, and Sourcegraph Cody maps business logic distribution in seconds.

Day 1: Structural Coupling Analysis with CAST Imaging

CAST Highlight and CAST Imaging run automatically against read-only access to the monolith codebase, no manual engineer review required on day one itself. The tool maps which modules call which other modules and scores structural coupling density per module pair.

• High inbound coupling means many things break if the module changes, so extract it later.
• High outbound coupling means many integration points to preserve during extraction, so extract it later too.
• Shared table access flags a data ownership problem that needs resolving before extraction.
• Circular dependencies flag modules that can't be independently extracted until the cycle breaks.

The output feeds directly into candidate ranking: a coupling score per module, a database dependency map, a shortlist of modules with fewer than 3 outbound dependencies, and an anti-candidate list of modules with more than 8. Analyst time to review and interpret the output runs 2 to 3 hours, against 2 to 3 weeks for the traditional manual equivalent, roughly an 85% time reduction for comparable coverage.

Day 2: Temporal Coupling Analysis with CodeScene

Structural coupling shows which modules depend on each other in code. Temporal coupling shows which modules change together in practice, even when they look structurally independent. A module with low structural coupling may still change alongside three other modules every time, a sign of hidden logical coupling that surfaces as unexpected coordination overhead during extraction.

CodeScene or GitClear analyses 24 months of git commit history in 2 to 3 hours, against 1 to 2 weeks for manual git log analysis. It measures:

• Which files change together in the same commit most often
• The co-change percentage between module pairs (above 30% signals meaningful hidden coupling, above 50% signals strong coupling)
• Change frequency per module
• Author concentration, since a module touched by only one engineer is a documentation and knowledge-transfer priority.

Good signals include frequent but independent changes under 20% co-change, authorship spread across the team, and a change cadence distinct from other modules. A concerning signal is a module that looked structurally independent showing 60%-plus temporal coupling with something else, which means there's hidden logic worth investigating before you commit.

Days 3 to 4: Business Logic and Domain Mapping with Sourcegraph Cody

Days one and two give you structural and temporal coupling data. Days three and four add the business logic dimension, whether each candidate module's purpose is understood well enough to extract safely.

For each candidate module, roughly 30 minutes of targeted semantic search with Sourcegraph Cody answers four questions:

• What business rules does this module implement, surfacing every function, conditional branch, and constant that encodes a business decision
• What does it call outside itself, identifying outbound dependencies the structural analysis may have missed
• What calls into it, determining the API surface that has to survive extraction
• Where else are its database tables accessed, often the most surprising finding of the whole exercise

Copilot Chat then generates a plain-English business capability summary, a list of the business events the module processes, and an answer to what breaks in the business if the module goes offline for 24 hours. A domain expert validates each summary, roughly 30 minutes per candidate. Analyst time runs 4 to 6 hours a day across 2 days for 3 to 5 candidate modules, against 1 to 2 weeks per module traditionally, about a 70% time reduction for equivalent depth.

Day 5: Scoring, Ranking, and Selection Decision

Day five turns the accumulated AI output into a human decision, starting with scores compiled across five weighted dimensions: structural coupling, temporal coupling, domain clarity, migration feasibility, and business value.

Dimension	Weight	Tool
Structural coupling	25%	CAST Imaging
Temporal independence	20%	CodeScene
Domain clarity	20%	Sourcegraph Cody
Migration feasibility	20%	CAST + manual
Business value	15%	Business stakeholders

• Structural coupling scores highest at zero to one outbound dependencies with no shared tables, lowest above eight dependencies with deeply shared data, a clear extract-last signal.
• Temporal independence scores highest under a 10% co-change rate, lowest above 50%, where hidden coupling needs investigating first.
• Domain clarity scores highest with a named business owner, consistent vocabulary, and 12-plus months of stability, lowest where the domain itself is still contested.
• Migration feasibility scores highest with exclusively owned tables and two or fewer external integrations, lowest with heavily shared data and undocumented integration sprawl.
• Business value scores highest when a stakeholder can name a specific metric that improves by more than 20%, lowest when the improvement is purely technical with no business owner invested.

The afternoon decision meeting brings together the programme architect, engineering lead, business product owner, and ideally the executive sponsor, to present the top three candidates, validate the business value inputs, confirm the 90-day scope fits, and document the decision rationale. What comes out the other end is a first-service decision backed by an auditable evidence trail, not a guess.

The Services That Score Highest as First Extraction Candidates

Across dozens of enterprise monolith to microservices migration programmes, certain service types consistently land at the top of the candidate scoring matrix. Understanding why each scores well, and what can go wrong even with a high-scoring candidate, sharpens what to look for in your own system.

The Notification Service, a Consistent Top Performer

The notification service, covering email, SMS, push, and in-app notifications, consistently scores among the highest first-extraction candidates in CAST Imaging coupling analysis, and the pattern holds across e-commerce, SaaS, healthcare, financial services, and logistics systems alike.

• Structural coupling averages 4.5 out of 5, since notification modules receive events but rarely call back into core business logic. The exception is a notification module that's grown complex template logic tied to five-plus other modules.
• Temporal independence averages around 4.2, with notification code changing on a distinct cadence, typically under 15% co-change with other modules. A major overhaul like switching from email-first to push-first can temporarily inflate that coupling.
• Domain clarity averages 4.3, since notification is a clear capability rarely contested in DDD workshops.
• Migration feasibility averages 4.4, with clean data ownership over delivery logs, template configs, and preference settings, and outbound-only integrations to email and SMS gateways
• Business value sits lower at 3.8, since extraction typically improves delivery tracking, retry logic, and A/B testing, but if notification is already reliable, stakeholders may not see much upside without confirming the business case first.

The common first-extraction mistake here is scope creep, pulling in smart routing, preference management, and analytics alongside the core extraction. Those are separate capabilities for later iterations. The first extraction should do exactly what the monolith's notification module already does, nothing more. Teams weighing this kind of decomposition work often pair it with broader software development services to make sure the platform, CI/CD, and monitoring foundations are ready before the first extraction lands.

The Reporting or Analytics Read Module, a Strong Alternative

Read-only reporting modules consistently score near the top of candidate matrices for one fundamental reason: a read-only service can't corrupt business data on failure.

• No write path means no risk of corrupting business data during parallel running, something CAST Imaging confirms by distinguishing SELECT-only modules from anything with insert, update, or delete operations.
• Reporting queries carry a different scaling profile than transactional queries, so independent scaling after extraction often trims infrastructure cost immediately.
• Reporting requirements change at the pace of business analysis requests rather than transactional logic, giving the module a genuinely independent change cadence, which CodeScene confirms across most systems analysed.
• Extraction here naturally leads toward a CQRS read model, teaching the team that pattern before it's needed elsewhere.
• Verification stays simple: run the same report against both the monolith and the new service and compare outputs, a comparison Diffblue Cover can largely automate.

Document Generation Service, Often Overlooked, Frequently Ideal

PDF generation, document export, contract generation, and invoice production are pure input-output operations that score well across every technical dimension.

• Stateless, since every call takes inputs and produces a document with no persistent side effects
• Testable, since output is deterministic for given inputs
• Independent, since it's called from many places but calls back into nothing

Business value is the limiting factor here. Unless document generation is a genuine pain point, slow PDF rendering causing complaints, unreliable contract generation causing tickets, stakeholders may not see compelling value in extracting it first as part of a broader microservice extraction strategy. Confirm the business case before choosing document generation as your first service. Getting this kind of prioritisation right often comes down to having enterprise app development expertise in the room, since these are exactly the calls that benefit from people who've watched a few extraction programmes succeed and fail.

Authentication and Identity, a High Score with Important Caveats

Authentication modules often score well on structural coupling since they're called from everywhere but call back into relatively little for pure authentication. That creates a coupling score that can genuinely mislead.

• Structural coupling often lands 3.8 to 4.2, and temporal coupling 3.5 to 4.0, both of which look solid on paper.
• What the score misses is criticality: authentication sits on the critical path of every user request, so a failure in the first extraction disrupts everyone, not a subset.
• It also misses implicit coupling, since auth modules often embed profile lookups, permission checks, and session management that conceptually belong to different bounded contexts entirely.
• Regulated systems layer compliance requirements of their own onto authentication, adding extraction complexity.

Evaluate authentication as a first candidate only after Sourcegraph Cody has fully mapped the business logic embedded inside it. If it's genuinely limited to token issuance and validation through OAuth 2.0 or OIDC, it can work as a first candidate. If it also handles profile management, permission rules, or MFA state, it's too complex for a first extraction. Worth considering the alternative too, since Auth0, AWS Cognito, Keycloak, and Azure AD B2C are production-grade identity providers, and replacing rather than extracting is often faster than building a custom auth service from scratch. This is exactly the kind of judgement call where enterprise digital transformation services expertise earns its keep, since the right answer depends on the whole platform roadmap, not just this one module.

Services That Reliably Score Lowest, Extract Last, Not First

Service	Why it scores poorly	Extract when
Core transaction engine (orders, payments, trades)	Highest business criticality, highest coupling, largest data footprint. Coupling score typically 1.0 to 2.0.	Last, once the team has full extraction proficiency and the platform is battle-tested.
User or account management	High inbound coupling; conflates identity, profile, billing, and permissions into one bounded context.	After authentication and notification, once sub-contexts are cleanly separated.
Inventory or product catalogue	Core domain with the highest coupling to everything else. Shares data with pricing, ordering, and search.	Near the end, after dedicated data architecture work.
Financial ledger or accounting engine	Highest regulatory sensitivity, ACID requirements are hard to replicate in a distributed architecture.	Only after saga pattern proficiency and regulatory sign-off.
Search built on a shared database	Full-text indexes drawn from multiple module tables, needing an event-driven read model first.	After event streaming infrastructure is in place.

The 90-Day Constraint, Scoping the First Extraction for Visible Value in Time

The highest-scoring candidate from the five-criterion matrix isn't automatically the right first service. It also has to satisfy the 90-day constraint, delivering visible business value within 90 days of programme start. That constraint is the organisational commitment mechanism that keeps executive sponsorship alive, and it's a factor every credible microservice extraction strategy has to account for from the outset. A first extraction that takes six months before showing value risks losing the sponsorship that funds everything after it.

With AI assistance, per-service extraction averages 6 to 11 engineering weeks. For a 90-day window with a 10-person team, that typically means the first extraction needs to fit inside 8 to 10 engineering weeks, once ramp-up, platform setup, and review cycles are accounted for. Every check here still traces back to the underlying structural coupling and dependency picture built during the five-day analysis.

Scope Validation Checks for the 90-Day Constraint

Five quick checks confirm whether a candidate genuinely fits inside the 90-day window before the team commits to it.

LOC Estimate for Extraction

Count lines of meaningful business logic, excluding generated code, config, and tests, using CAST Highlight. Under 15K lines fits a 90-day first extraction; anything larger needs scope reduction.

Outbound Dependency Count

Count the distinct external calls the module makes that need preserving or replacing, using CAST Imaging with Sourcegraph confirming each call site. Five or fewer dependencies fit the scope.

Data migration scope

Count data tables exclusively owned by the module, using CAST Imaging's table ownership analysis. Three or fewer tables fit a 90-day extraction.

Integration Complexity

Count integrations with external systems and partner APIs that need maintaining through the extraction. Three or fewer external integrations fit the scope.

Diffblue Cover Test Generation Feasibility

Run a Diffblue Cover preview on the candidate module. Coverage above 60% in the preview run means testing will comfortably fit the 90-day constraint; below that, budget additional manual testing time.

Scope Reduction Strategies When the Top Candidate Is Too Large

The highest-scoring candidate is sometimes simply too big for a 90-day first extraction. Scope reduction, extracting a well-defined subset rather than the full module, is a disciplined application of the Strangler Fig principle, not a compromise.

Extract The High-Frequency Path Only

If the notification service handles email, SMS, push, and in-app, extract email alone first, since it typically carries 80% of volume and the business sees measurable improvement immediately.

Extract the Read Path First

If a reporting module handles both query execution and report configuration, extract query execution only for the first 90 days. Configuration stays in the monolith temporarily and follows once the pattern is proven.

Extract the Independent Function Within a Complex Module

If document generation produces PDFs, Excel exports, and Word documents, extract PDF generation alone first, since it's usually the most requested and most performance-constrained function.

Scope reduction is not delivering an incomplete service to production, not a proof of concept, and not a quality compromise. It's a fully production-ready, well-tested, well-documented service handling a specific, well-defined subset, with the remaining scope assembled across two or three later extractions.

AI Tool Calibration for First-Service Analysis, Getting Maximum Value

AI analysis tools don't perform equally well on every codebase. A poorly configured or uncalibrated tool produces misleading structural coupling scores that lead straight to the wrong candidate. Before running the five-day analysis, spend one day confirming the tools are producing accurate output for your specific codebase.

CAST Imaging Calibration Checklist

• Verify language coverage. CAST supports Java, .NET, Python, PHP, JavaScript, COBOL, and SQL, but confirm the specific versions in your codebase are covered, since unsupported components leave gaps in the dependency graph.
• Verify build system integration. For Maven, Gradle, or MSBuild, confirm project references resolve correctly. For Python, confirm virtual environment dependencies are visible.
• Validate against known coupling. Pick two modules you already know are coupled and confirm CAST Imaging shows that coupling. If it doesn't, resolve the configuration issue before candidate analysis starts.
• Check dynamic call resolution. Spring dependency injection, reflection-based calls, and interface implementations may not resolve cleanly in static analysis.
• Verify database table analysis. Run table access analysis on two known modules and confirm the tables identified are correct, since wrong table analysis produces wrong data dependency conclusions downstream.

Sourcegraph Cody Calibration for Your Codebase

Sourcegraph Cody's semantic search quality depends on index completeness and context window configuration. Before day three candidate analysis for the first microservice to extract begins, ask it a question you already know the answer to, such as where customer authentication logic lives, and confirm the answer is correct and complete. Missed locations usually mean an incomplete index, so confirm every repository in the monolith is indexed, including shared libraries that might live in separate repos. For codebases above 500K lines, confirm Cody is using an appropriately large context window, since default settings can produce incomplete answers at that scale.

Diffblue Cover Test Preview, Validating Before Committing

Before selecting a first service partly on the assumption that Diffblue Cover will generate strong tests efficiently, run a preview on each top candidate. It takes 2 to 3 hours per module and gives you the actual test coverage percentage the tool will achieve. A candidate scoring 4.5 out of 5 on structural coupling but only managing 30% test coverage in preview may need reclassifying, since testing will run slower and more expensively than expected.

• Above 70% coverage in under 2 hours means the testing phase will be fast and high quality, so proceed with confidence.
• Between 50 and 70% is still good, though it means planning explicitly for manual test augmentation.
• Between 30 and 50% suggests complex patterns, heavy dependency injection, or excessive mocking, and needs extra manual testing time factored into the 90-day estimate.
• Below 30%, or an outright Diffblue failure, points to code quality patterns AI test generation handles poorly, worth a different candidate or upfront code quality work.

Worked Example, First Service Candidate Analysis for a B2B SaaS Monolith

To make the five-day analysis concrete, here's a realistic worked example based on a composite of B2B SaaS platform patterns. The system is a 220K-LOC Java Spring monolith with roughly 12 natural module boundaries, a PostgreSQL database, and a team of 45 engineers across 4 product squads.

Day 1: CAST Imaging Top Candidates

Module	Outbound deps	Shared tables	Score	Verdict
Notification (email + SMS)	2	0	4.6/5	Strong candidate
Audit Log / Activity Feed	1	0	4.4/5	Strong candidate
PDF Report Generator	1	1	4.2/5	Good candidate
User Authentication	3	2	3.4/5	Needs Sourcegraph review
Webhook Delivery	2	0	4.5/5	Strong, but low business value expected
Billing / Subscription (reference)	7	5	1.8/5	Extract last
Core Project Management Engine (reference)	9	8	1.2/5	Extract last

Day 2: CodeScene Temporal Coupling

The CodeScene pass surfaces a critical finding: the authentication module shows 65% temporal coupling with the notification module, an unexpectedly high figure that pulls its temporal score down to 2.5 out of 5 despite otherwise looking decent. That flag sends the day three and four Sourcegraph analysis straight to the question of whether auth is calling notification logic directly, or whether the two just happen to change together for unrelated reasons. Either way, this single finding shifts auth from a moderate candidate to one needing deeper investigation.

Days 3 to 4: Sourcegraph Cody Findings

The notification module turns out clean: email and SMS delivery, template management, delivery tracking, and retry logic, calling out to SendGrid and Twilio with no calls back into core business logic, a genuine fire-and-forget pattern. It owns three tables outright, and the Head of Customer Success confirms business ownership within 30 minutes. Domain clarity lands at 5 out of 5.

The audit log module records actions across all modules, writes to two exclusively owned tables, and gets called from 12 other modules to log events. The Head of Compliance confirms ownership quickly, but also flags the module as mission-critical for regulatory reasons, which raises the real extraction risk above what the coupling score alone would suggest. Domain clarity lands at 4 out of 5, with that compliance caveat attached.

The investigation into auth's 65% temporal coupling resolves cleanly: auth calls notification to send verification emails, which is exactly what's driving the co-change pattern. These are two coupled modules, not one isolated service, and the fix is straightforward. Extract notification first. Once that's done, the auth-to-notification coupling becomes a cross-service API call instead of in-process coupling, which makes auth a much cleaner second extraction.

The webhook delivery module is technically about as clean as notification, with two exclusively owned tables and outbound-only HTTP calls to customer endpoints, but nobody can point to a compelling business improvement from extracting it right now. Business value lands at 2 out of 5, technically tidy but a weak business case.

Day 5: Final Scoring and Decision

Dimension	Weight	Notification	Audit Log	PDF Generator	Webhook
Structural coupling	25%	1.15	1.10	1.05	1.13
Temporal independence	20%	0.90	0.86	0.80	0.88
Domain clarity	20%	1.00	0.80	0.90	0.70
Migration feasibility	20%	1.00	0.90	0.80	1.00
Business value	15%	0.60	0.45	0.53	0.30
Total	100%	4.65	4.11	4.08	4.01

The notification service wins by a meaningful margin. The Sourcegraph investigation confirms the auth temporal coupling resolves itself once notification is extracted first, setting up a cleaner subsequent auth extraction. Audit log comes second, though the elevated compliance concern tempers confidence. PDF generator lands third, a solid candidate for the second or third extraction.

AI-assisted scope validation confirms the fit: the notification module is 8K lines of meaningful business logic, two outbound dependencies, three exclusively owned tables. A Diffblue Cover preview hit 74% test coverage in 90 minutes. The 90-day constraint is easily satisfied, and the decision goes forward with a full evidence trail behind it.

How Mobisoft Runs First-Service Selection

Mobisoft offers first-service selection as a standalone two-week engagement, and also as the natural first phase of a broader monolith-to-microservices programme.

Week one runs the AI analysis:

• CAST Imaging coupling analysis across the full codebase from day one
• CodeScene temporal coupling analysis across 24 months of history
• Sourcegraph Cody mapping the top five candidate modules in full
• A Diffblue Cover test preview on the top three candidates
• Tool calibration validated before the real analysis begins

Week two turns that into a recommendation:

• The scoring matrix completed for all top candidates
• Business value validated directly with the business product owner
• The 90-day scope confirmed for the recommended candidate
• Scope reduction options documented if needed
• A sequencing recommendation for the next five services
• The final decision presented to engineering leadership and the executive sponsor

What you walk away with is a scored candidate matrix with a full, auditable evidence base, a first-service recommendation with documented rationale, a sequencing plan for the following five services, a defined 90-day extraction scope, validated AI toolchain configuration, and a Diffblue Cover test coverage preview for the selected service. Cost runs $15K to $40K depending on codebase size and candidate count, over a two-week timeline.

This engagement stands alone, or it can open into a full programme delivery engagement. If the evidence points to unexpected areas like a modular monolith first, or a different first service than anyone assumed going in, we say so. The evidence leads, not the anticipated outcome.

Getting the First Extraction Right

Microservice decomposition succeeds or struggles on the first move. A five-criterion framework, run through five days of AI-assisted analysis instead of weeks of manual tracing, replaces guesswork with an auditable decision. Structural coupling, temporal coupling, domain clarity, migration feasibility, and business value, weighted together, consistently point toward the same handful of strong candidates: notification services, read-only reporting, and document generation, with authentication as a caveated option and core transactional engines reserved for later.

Get this right, and the programme inherits a strong pattern. Get it wrong, and every extraction after it inherits the flaws instead, and organisational patience runs thinner with each one. If you're planning a monolith-to-microservices migration and want that first decision grounded in real evidence rather than instinct, Mobisoft's team can run the five-day analysis against your actual codebase and hand you a scored, defensible recommendation.