An S/4HANA brownfield migration can look straightforward on a project plan because the source system already contains years of configuration, master data, transactions, and tested business rules. The difficult part is that S/4HANA doesn’t preserve every ECC design unchanged. Some MM and SD settings remain familiar, while others sit directly on simplification items, new data models, or replacement functions. Those differences can turn a technical conversion into months of functional remediation if they are found late.
The schedule impact usually doesn’t come from changing a few SPRO settings. It comes from the work around those settings: correcting master data, adapting custom code, rebuilding process logic, retesting interfaces, reconciling converted values, and repeating user acceptance tests. SAP’s current Conversion Guide for SAP S/4HANA 2025 places preparation and consistency checks before the technical conversion because unresolved simplification items can stop or complicate later steps. That makes early functional analysis a schedule control, not paperwork.
For teams planning an S/4HANA system conversion, the most useful question isn’t whether MM and SD are in scope. They almost always are in a mature ECC landscape. The useful question is which parts of SAP MM configuration and SAP SD configuration touch mandatory S/4HANA changes, historical data, custom programs, integrations, or business processes that must be redesigned. The 7 steps below are the areas most likely to answer that question.
TL;DR
The biggest MM and SD timeline risks in an S/4HANA brownfield migration are concentrated in 7 configuration areas: Business Partner and CVI, Material Ledger and valuation, pricing and condition logic, Credit Management, rebates and Settlement Management, foreign trade, and output management. Some are mandatory foundations, while others matter only if the ECC system uses the older function.
SAP’s 2025 Simplification List makes an important planning point in the middle of its conversion guidance: no single customer is expected to be affected by every simplification item. The right timeline therefore comes from mapping these changes to actual source-system use, then estimating the data cleanup, code changes, process redesign, and testing that follow.
A practical rule is simple. Treat Business Partner/CVI and Material Ledger as early readiness topics. Treat pricing, credit, rebates, foreign trade, and output as usage-driven scope that must be proven by source-system analysis. This keeps the SAP S/4HANA migration plan tied to real dependencies instead of generic workstream estimates.
Why MM and SD Configuration Changes Affect Brownfield Timelines
Brownfield projects inherit both strengths and liabilities from ECC. Existing configuration shortens design work because the company already knows how purchasing, inventory, sales, pricing, credit, and document output operate. The same inheritance can slow the S/4HANA system conversion when old settings depend on functions that changed underneath them.
A configuration item affects the timeline when it creates work outside the configuration transaction itself. A changed account-group mapping may require customer cleanup. A pricing table change may expose custom ABAP that reads an old persistence table. A new credit model can alter order blocking and release. An output decision can affect forms, email routing, EDI, and print tests. These are cross-workstream effects, which is why a small functional decision can create a large schedule consequence.
The first planning step should therefore be relevance analysis. SAP’s conversion material says the Simplification Item Check identifies items that apply to the source system, and SUM uses those checks during conversion. In parallel, SAP S/4HANA product guidance points conversion teams to the Conversion Guide and Simplification List as release-specific sources. That pairing matters because the target release determines which checks, functions, and follow-on tasks apply.
The rest of the article treats each of the 7 steps in the same way: what changes, why it expands work, what should be checked before the first serious sandbox cycle, and which tests prove that the process still works.
Set Up Business Partner and CVI Before Conversion Pressure Builds
Business Partner conversion should be treated as a foundation item because SAP S/4HANA uses Business Partner as the leading object for customer and supplier master data. For an S/4HANA brownfield migration, this affects both MM and SD at once. Suppliers support purchasing processes, while customers support order-to-cash. A CVI problem can therefore block master-data readiness across 2 core workstreams.
SAP states in its Business Partner approach for Customer/Supplier Integration that customers moving from SAP ERP need Customer/Supplier Integration in place and that all customers and suppliers must be converted to Business Partners. The same guidance also warns that Customizing must be maintained correctly so the data can be converted completely. That makes CVI preparation a precondition rather than an optional cleanup exercise.
What the Configuration Team Must Align
The SAP MM configuration and SAP SD configuration review should include account groups, BP groupings, number ranges, field status, role assignment, and synchronization settings. The goal is to make the ECC customer or supplier structure map cleanly into the BP model without losing required attributes or creating number conflicts.
The difficult part often appears in data rather than SPRO. Old ECC systems may contain duplicate tax IDs, inconsistent address data, one-time accounts, obsolete records with deletion flags, missing mandatory fields, or custom account-group rules that were added years ago. CVI synchronization exposes those inconsistencies because the source object and BP object need a valid relationship.
Why It Affects the Timeline
A team that discovers CVI errors during the main conversion rehearsal now has 3 jobs at once: repair configuration, clean master data, and rerun synchronization. That work often needs functional owners because not every duplicate or missing field can be fixed safely by a technical rule. Procurement may need to decide which supplier record survives. Sales may need to resolve duplicate sold-to accounts. Finance may need to confirm company-code data.
For an S/4HANA brownfield migration, the safer sequence is to run CVI preparation before the conversion calendar becomes tight. Build the mapping, synchronize a representative population, classify errors, repair repeatable data patterns, then rerun until the exception volume is small enough to manage. This turns BP work into a controlled readiness activity instead of an emergency inside the S/4HANA system conversion.
Align Material Ledger and Inventory Valuation
Material Ledger is the MM configuration item most likely to surprise teams that treat S/4HANA as a technical database move. In S/4HANA, Material Ledger is mandatory. Actual Costing remains optional. Those 2 statements need to stay separate because many project plans incorrectly treat them as the same requirement.
SAP’s current Material Ledger installation guidance states in the middle of the setup instructions that Material Ledger is mandatory as of S/4HANA and Actual Costing is still optional. It also points to specific financial migration steps for systems upgraded from SAP ERP. That link between MM valuation and financial conversion is why this topic can influence more than the procurement workstream.
What Needs to Be Checked
The SAP MM configuration review should cover valuation areas, company-code currency settings, material valuation, price control, existing Material Ledger use, and any plant-level exceptions. If the company already runs Material Ledger in ECC, the question is whether the design is consistent with the target S/4HANA rules. If it doesn’t, the team needs to decide how to activate and validate it for the conversion.
Currency settings deserve attention because valuation structures feed accounting. A plant that doesn’t align with the company-code valuation design can produce migration or reconciliation work that appears late. The same applies to materials with unusual valuation history or custom reporting that reads legacy inventory tables directly.
Why It Affects the Timeline
Inventory valuation sits at the meeting point of MM and Finance. A technical conversion can finish while business acceptance still fails because opening values don’t reconcile, material prices look wrong, or custom reports return different totals. That means Material Ledger planning needs an explicit reconciliation path, not only a configuration transport.
For an S/4HANA brownfield migration, a sensible sequence is to confirm valuation design before the first sandbox, identify material populations that need special review, and agree on reconciliation reports with Finance. The first converted system should then be used to prove stock values, moving average prices, standard prices where relevant, and postings for key goods movements. That work makes the SAP S/4HANA migration estimate more defensible because it captures the validation effort that follows the conversion utility.
Review Pricing Procedures and Condition Logic for New Persistence
Pricing looks familiar to many SD consultants after conversion because condition types, access sequences, condition tables, and pricing procedures still exist. The hidden timeline risk is the data model underneath them. S/4HANA stores pricing results differently from ECC, so custom code and extensions built around old pricing persistence can fail even when the standard configuration appears intact.
SAP’s current learning content on S/4HANA sales data model simplifications explains that pricing results move to PRCD_ELEMENTS and that KONV is no longer the persistence table for those results. The guidance also notes fallback read access through a CDS view for older pricing results. This is exactly the type of change that can leave standard SAP SD configuration working while custom programs still need repair.
What Should Be Reviewed
The SD configuration team should inventory custom condition tables, condition types, access sequences, pricing procedures, requirements, formulas, and VOFM routines. Then the ABAP team should search for custom objects that read or update KONV, rely on appended fields, or assume ECC field lengths and structures.
The same discipline applies to purchasing conditions where custom logic crosses MM pricing. If a custom report or interface extracts purchase-order condition data from old structures, it belongs in the S/4HANA system conversion test scope even if the project is discussing the issue under SD pricing.
Why It Affects the Timeline
Pricing defects have a wide blast radius. A single bad requirement or code adaptation can affect quotations, orders, returns, billing, taxes, discounts, surcharges, and intercompany scenarios. The defect may only appear with a specific sales area, customer group, document type, or condition combination, which makes shallow testing risky.
An S/4HANA brownfield migration should therefore build a pricing regression set from real business patterns before conversion. Include high-value and high-volume procedures, manual conditions, exclusion logic, free goods where used, intercompany pricing, tax paths, and custom formulas. The goal isn’t to retest every historical sales order. It is to prove each distinct pricing behavior that the SAP S/4HANA migration could change.
Convert Classic Credit Management Deliberately
Classic FI-AR Credit Management is one of the clearest examples of a functional replacement that can widen a brownfield schedule. If ECC still uses FI-AR-CR for sales credit checks, the target design moves to SAP Credit Management in FSCM. This isn’t a cosmetic transaction-code change. It affects configuration, master data, exposure, checks, and operational release processes.
SAP’s Credit Management configuration guide includes a conversion task list for customers using FI-AR-CR in SAP ERP and describes the move to FIN-FSCM-CR in S/4HANA. It calls out configuration data, master data, credit exposure, and credit decision data as conversion concerns. Those categories show why credit can become a workstream of its own inside an S/4HANA brownfield migration.
What Changes Functionally
The SD configuration review should trace how ECC currently determines credit control, risk categories, limits, automatic checks, blocked-document handling, and release authority. Then the target design must map those controls into SAP Credit Management and Business Partner-based master data.
Custom exits and interfaces need equal attention. Some ECC landscapes send external credit information, calculate exposure with custom logic, or feed blocked sales orders into workflow. Those extensions may require redesign if they depend on classic structures or transactions.
Why It Affects the Timeline
Credit checking sits directly in order entry. A converted system can pass technical validation yet fail business testing because valid orders are blocked or risky orders are released. That creates high-pressure defects during SIT and UAT because users can’t complete normal sales flows.
An S/4HANA brownfield migration should test credit behavior by business scenario rather than transaction alone. Use customers near their limit, overdue exposure cases, high-value orders, partial deliveries, billing updates, and release paths. Also validate what happens when exposure changes after subsequent documents post. This gives the SAP SD configuration team evidence that the new credit setup preserves the control intent of ECC.
Move Rebate Processes to Settlement Management Where They Apply
Rebates are a conditional timeline driver. If the company doesn’t use classic customer or supplier rebates, this step may have little effect. If rebates are central to pricing and margin, the move matters because S/4HANA uses Settlement Management and condition contracts for the replacement process.
SAP’s Settlement Management overview states that Settlement Management replaced the old MM and SD rebate settlement processes used in ERP. Current S/4HANA documentation also shows that condition contracts support sales and purchasing rebate scenarios. This means both SAP MM configuration and SAP SD configuration can be affected when the source system uses supplier or customer rebates.
What the Team Must Map
Start with the business agreement, not the old transaction. Identify rebate types, validity periods, accrual behavior, settlement dates, eligible business volume, exclusion rules, and the accounting outcome. Then map those requirements to condition contract types, settlement calendars, pricing used by settlement documents, and the related posting logic.
A sales rebate design can also contain custom fields or approval logic. Current SAP guidance for sales rebate extensibility describes custom fields and custom logic around condition contracts and settlement documents. That matters when ECC rebate agreements were extended with business-specific attributes that users still need after conversion.
Why It Affects the Timeline
Rebates have historical and financial consequences. Open agreements may span the conversion date. Accruals may already exist. Settlements may be scheduled after go-live. The project therefore needs a clear rule for what stays historical, what moves, and how open business is treated.
For an S/4HANA brownfield migration, testing must prove more than contract creation. Run partial settlement where used, final settlement, accrual updates, reversals, and accounting postings. For purchasing rebates, test supplier-side settlement as well as the related financial result. These scenarios can add cycles to an S/4HANA system conversion because defects often appear only when enough transaction history exists to calculate settlement correctly.
Rework Legacy Foreign Trade Dependencies
Foreign trade can become a hidden brownfield risk because old ECC functions often sit inside ordinary MM and SD documents. Users may see commodity codes, export fields, or customs data as small attributes on a material, purchase order, delivery, or billing document. The underlying target architecture may be different.
Current SAP S/4HANA documentation describes International Trade functions for trade classification, compliance, Intrastat, and integration with SAP Global Trade Services. That target scope should be compared with the exact legacy Foreign Trade functions used in ECC instead of assuming a one-for-one configuration carryover.
What to Trace in the Source System
The SAP MM configuration team should identify product classifications, supplier-related trade data, purchase-document fields, and import process dependencies. The SAP SD configuration team should trace customer, sales-document, delivery, billing, export, and compliance-related requirements. Interfaces to brokers, customs systems, or SAP GTS also need to be inventoried.
For landscapes that depend on SAP GTS, SAP’s current S/4HANA integration guidance explains how an external GTS system can connect to S/4HANA and exchange master and transaction data. That integration point can add timeline work because mappings, queues, and document transfers must be retested against the converted feeder system.
Why It Affects the Timeline
Trade processes cross organizational boundaries. A change in SAP may require coordinated testing with compliance teams, logistics partners, customs brokers, or a separate GTS landscape. That coordination creates calendar risk even when the configuration itself is manageable.
An S/4HANA brownfield migration should decide the target trade architecture before SIT begins. Test classifications, document transfer, blocked-document handling, Intrastat where relevant, and the fields required by external systems. If the business ships internationally on day 1, foreign trade can’t be left as a post-go-live cleanup item in the SAP S/4HANA migration plan.
Decide Whether to Keep Existing Output or Adopt S/4HANA Output Control
Output management is often estimated badly because teams hear that S/4HANA has a new output framework and assume every brownfield project must replace NAST during conversion. Current SAP guidance doesn’t support that blanket conclusion for on-premise and private-edition scenarios. Existing output solutions can still be used for applications where they remain supported.
SAP’s current S/4HANA Output Control documentation says in the conversion section that existing output frameworks remain supported and customers can decide at application level which framework fits their scenario. This makes output a design decision in many brownfield projects, not a universal prerequisite.
What Must Be Decided Early
For each MM and SD document family, classify the target as keep, replace, or retire. Purchase orders, contracts, sales documents, delivery-related outputs, invoices, email messages, print jobs, EDI, and forms may use different frameworks. The answer doesn’t need to be the same for every application.
If the project chooses S/4HANA output control, the configuration model changes from classic message determination. SAP’s learning material on S/4HANA output management in Materials Management explains that the newer approach uses different configuration from NAST and is available for purchasing documents such as requests for quotation, purchase orders, and purchase contracts. That difference can add rules work, form work, and test cases.
Why It Affects the Timeline
Output defects are easy to miss in technical testing because the document itself may post successfully. The failure appears later when a supplier doesn’t receive a purchase order, a customer invoice isn’t emailed, an EDI message has the wrong data, or a form loses required fields.
In an S/4HANA brownfield migration, treat output as an end-to-end acceptance test. For each important document, prove trigger logic, recipient determination, channel, form rendering, language, partner data, attachments where used, and reprocessing after errors. If the team decides to modernize output during the S/4HANA system conversion, estimate that as added functional scope instead of hiding it inside technical conversion effort.
How to Sequence the 7 Steps Across the Brownfield Plan
The 7 steps shouldn’t all begin at the same time. Some affect technical readiness, while others are better handled once the converted sandbox exists. A practical sequence keeps prerequisite work ahead of SUM and reserves behavior testing for the target environment.
| Timing | Primary Work | Why It Belongs There |
| Before first conversion rehearsal | CVI mapping and synchronization | BP readiness can expose blocking master-data and configuration errors |
| Before first conversion rehearsal | Material Ledger and valuation review | Valuation settings affect migration and reconciliation |
| Before or alongside first sandbox | Pricing dependency scan | Custom KONV and pricing code findings need time for repair |
| Early target design | Credit Management mapping | Classic credit processes need a target FSCM design before testing |
| Early target design if used | Settlement Management mapping | Open rebate agreements and accruals need a treatment rule |
| Before integration test design | Foreign trade target mapping | Interfaces and compliance processes need coordinated tests |
| Before form and channel testing | Output framework decision | Keeping or replacing output changes the test and build scope |
A useful companion activity is custom-code analysis. SAP’s current Custom Code Analysis guidance explains that S/4HANA migration projects can run S/4HANA custom-code checks and identify unused code. That matters here because pricing, foreign trade, output, credit, and valuation changes often surface through custom programs rather than through configuration alone.
The SAP S/4HANA migration schedule should also separate mandatory conversion work from optional modernization. CVI and Material Ledger are tied closely to the target S/4HANA foundation. Switching every possible document to the newest output framework during the same project may be a choice. Replacing an old rebate process may be mandatory only when that process is actually used. Keeping these categories separate prevents the SAP S/4HANA migration from becoming a broad redesign program without an explicit decision.
How These Configuration Steps Expand Testing and Cutover
Configuration changes become timeline changes when they increase the number of business outcomes that must be proven. A transport can take minutes. A defect found in integrated order-to-cash or procure-to-pay testing can take days because the cause may sit in master data, code, configuration, or converted history.
Testing should be risk-based. CVI needs customer and supplier lifecycle tests. Material Ledger needs valuation and posting reconciliation. Pricing needs representative condition combinations. Credit Management needs exposure and block-release cases. Settlement Management needs agreement-to-accounting tests. Foreign trade needs classification and interface tests. Output needs channel and form tests.
The team should also test cross-step dependencies. Business Partner data feeds credit and output recipient determination. Pricing can feed rebate business volume. Material valuation can affect purchasing and accounting results. Foreign trade classifications can sit on product data used by sales and procurement. Testing each configuration item in isolation won’t prove those connections.
Cutover planning should identify which activities must be repeated in production and which are transport-driven. CVI synchronization status, open rebate treatment, credit exposure migration, output activation, and interface switching may need cutover checkpoints. Those checkpoints belong in the rehearsal plan so the production weekend isn’t the first time the team performs them in sequence.
Common Planning Mistakes That Distort Brownfield Estimates
The first mistake is estimating by module instead of by dependency. Saying “MM gets 8 weeks and SD gets 8 weeks” ignores the fact that CVI, credit, output, and trade processes cross functional boundaries. The work is better estimated by object population, custom dependency, integration count, and test scenario count.
The second mistake is treating every S/4HANA change as mandatory redesign. That inflates the project and hides true prerequisites. Output management is a good example: supported legacy frameworks can remain in use, while adopting the newer framework adds scope. The same thinking should be applied anywhere SAP provides transition choices.
The third mistake is assuming standard configuration means low risk. Pricing can use standard procedures and still have dozens of custom programs reading KONV. Credit can use familiar sales-document checks while relying on custom workflow. Foreign trade can look small in SPRO while feeding a separate compliance platform. An S/4HANA brownfield migration needs both configuration analysis and dependency analysis.
The fourth mistake is waiting for UAT to validate converted data. Business users are valuable testers, but UAT is expensive time for discovering basic master-data or valuation defects. CVI errors, inventory reconciliation gaps, and missing condition data should be reduced during sandbox and SIT cycles so UAT focuses on business acceptance.
A Readiness Checklist for MM and SD Leads
Before the first production-like rehearsal, MM and SD leads should be able to answer the following questions with evidence rather than assumptions.
• Have all relevant customer and supplier account groups been mapped to Business Partner groupings and roles?
• Can CVI synchronization complete for the active population with a controlled exception list?
• Are Material Ledger and valuation settings consistent with the target company-code and plant design?
• Has custom code that reads pricing persistence been identified and assigned for remediation?
• Have the business-critical pricing procedures and condition paths been turned into regression tests?
• If classic credit is used, is the SAP Credit Management target design complete and tested with representative exposure cases?
• If customer or supplier rebates are used, is there a documented treatment for open agreements, accruals, and settlement after go-live?
• If legacy Foreign Trade is used, has each requirement been mapped to S/4HANA International Trade, SAP GTS, or another target process?
• Has every critical MM and SD output been classified as retained, replaced, or retired?
• Are interfaces and forms included in SIT rather than left for business users to discover in UAT?
• Are cutover steps for these 7 areas rehearsed with named owners and completion evidence?
This SAP S/4HANA migration checklist is intentionally functional. Basis readiness, infrastructure, SUM planning, and database sizing still matter, but they don’t replace the MM and SD work described here. A credible S/4HANA system conversion plan needs both technical readiness and functional proof.
Conclusion
The MM and SD configuration choices that change a brownfield schedule are the ones connected to S/4HANA simplifications, converted data, custom code, interfaces, or end-to-end business controls. Business Partner/CVI and Material Ledger deserve early attention because they sit close to the target foundation. Pricing, credit, rebates, foreign trade, and output should be scoped from actual ECC usage rather than copied from a generic checklist.
The practical lesson for an S/4HANA brownfield migration is to move discovery forward. Find CVI errors before the main rehearsal. Find KONV dependencies before pricing UAT. Decide the credit target before order testing. Map rebates and trade requirements before integration cycles. Decide the output strategy before forms become a cutover surprise.
SAP MM configuration and SAP SD configuration still provide much of the familiar business structure after conversion, but familiar screens don’t guarantee familiar behavior. The project timeline becomes more predictable when each of these 7 steps has an owner, source-system evidence, a target decision, and a test path before the production conversion date is fixed.
FAQs
What Is an S/4HANA Brownfield Migration?
An S/4HANA brownfield migration converts an existing SAP ERP or ECC system to S/4HANA while preserving much of the existing configuration, historical data, and business process design. The project still needs remediation for S/4HANA simplifications, custom code, data consistency, and functions that changed or were replaced.
Which MM Configuration Step Should Be Reviewed First?
Business Partner/CVI and Material Ledger should be reviewed early. CVI affects supplier and customer master readiness across MM and SD, while Material Ledger affects inventory valuation and financial migration. The exact order can vary by source-system condition.
Is Material Ledger Mandatory in S/4HANA?
Yes. Material Ledger is mandatory in SAP S/4HANA. Actual Costing is optional. Teams should keep those 2 points separate when estimating configuration and testing work.
Does Every Brownfield Project Need to Redesign SD Pricing?
No. Standard pricing concepts remain familiar, but custom code or extensions that depend on ECC pricing persistence can require changes. The main task is to identify custom condition logic and code dependencies that may be affected by the S/4HANA pricing data model.
Why Does KONV Matter During Conversion?
S/4HANA stores pricing results in PRCD_ELEMENTS rather than using KONV as the persistence table in the same way as ECC. Custom programs that directly read or update old pricing persistence need to be checked and adapted where required.
Is Classic FI-AR Credit Management Available in S/4HANA?
Classic FI-AR Credit Management is replaced by SAP Credit Management in FSCM for the S/4HANA target. Companies that use classic credit checks need to plan the configuration, master-data, exposure, and process migration.
Do Rebate Processes Always Delay a Brownfield Conversion?
No. They matter when the source system uses classic customer or supplier rebate processing. In that case, the project needs a target Settlement Management design and a rule for open agreements, accruals, and settlements that cross the go-live date.
What Is Settlement Management Used for in S/4HANA?
Settlement Management supports processes such as customer and supplier rebates through condition contracts and settlement documents. It replaces older MM and SD rebate settlement approaches used in ERP.
Does Foreign Trade Need to Be Rebuilt in Every S/4HANA Project?
No. The work depends on which ECC Foreign Trade functions the company uses. Teams should map actual classification, compliance, Intrastat, customs, and interface requirements to S/4HANA International Trade or SAP GTS as appropriate.
Is S/4HANA Output Management Mandatory for Brownfield Projects?
No. For supported on-premise and private-edition applications, existing output frameworks can continue to be used. Moving to S/4HANA output control is often an application-level choice and should be estimated as added scope when selected.
How Does SAP MM Configuration Affect SD Testing?
MM and SD share dependencies through Business Partner data, product data, pricing-related logic, output, trade processes, and accounting integration. A change made for procurement can therefore affect downstream sales or financial behavior and should be tested across process boundaries where relevant.
How Does SAP SD Configuration Affect Cutover?
Credit data, open rebate treatment, pricing-dependent custom code, output activation, and customer master readiness can all create cutover activities. These tasks should be rehearsed during conversion cycles rather than designed for the first time during the production weekend.
What Is the Simplification Item Check Used For?
The Simplification Item Check identifies S/4HANA simplification items that are relevant to the source system and checks related consistency conditions. It helps teams separate applicable conversion work from changes that don’t affect their landscape.
How Many Test Cycles Are Needed for an S/4HANA System Conversion?
There is no fixed number that fits every project. The required cycles depend on source-system complexity, custom code, interfaces, data quality, business criticality, and how many defects are found during rehearsal. Projects should plan enough cycles to prove both technical conversion and business-process stability.
What Is the Best Way to Protect an SAP S/4HANA Migration Timeline?
Find functional dependencies before the schedule becomes fixed. Run relevance checks, prepare CVI, review valuation, scan custom code, map replacement functions, and build regression tests before the main conversion rehearsals. Early evidence gives the project a better basis for effort and cutover planning.