Scoping a SaaS ERP Migration Under Deadline

Scope should follow financial significance, change risk, and reliance risk, not the CIO’s preference. Include the SaaS ERP’s logical access, change management, interface monitoring, job scheduling, and segregation of duties because these directly affect financial reporting and prior-year deficiencies remain unresolved. Include the data migration, including completeness and accuracy of balances, open items, and master data, because migration errors can corrupt reporting from day one. Include the parallel-run reconciliation between legacy and SaaS ERP, and the vendor management control environment, including contract security terms, subservice organizations, and user entity controls in the SOC 1 report.

Exclude low-risk peripheral systems with no financial reporting impact and no interface to the ERP, and exclude legacy applications that are fully decommissioned before go-live except for cut-over and retention testing. Do not exclude change management just because the vendor hosts the application: the retailer still controls configuration changes, user roles, and report logic. Document exclusions with rationale and obtain audit committee acknowledgment. The scoping memo should map each in-scope area to risk, hours, and evidence source so the 1,100-hour budget is defensible.

You cannot rely on the report as a whole without evaluating the exceptions. A SOC 1 Type 2 gives evidence about the vendor’s controls over a period, but exceptions mean the controls did not operate as described for at least some tested items. The change management exception is significant because unauthorized or untested changes to the SaaS platform could affect financial processing. Reliance should be partial at most, and only for control areas with no exceptions and with effective complementary user entity controls.

Additional work should include: reading the auditor’s opinion, scope, period, and complementary user entity controls; assessing whether each exception is isolated or systemic; obtaining management’s remediation evidence and the vendor’s response; and determining whether the exception affects the specific transaction streams the retailer relies on. For change management, do not rely solely on the SOC 1 report. Test the retailer’s own change controls over configuration, integrations, and reports, and consider expanding testing of vendor changes that affect financial calculations. Document the reliance decision, the gap, and the compensating audit procedures. If the vendor cannot demonstrate remediation, plan substantive testing around affected interfaces and reports.

The plan should be phased and risk-based rather than a full annual ITGC audit. Phase one, before go-live, should cover migration completeness and accuracy, segregation of duties design, interface design, and the vendor SOC 1 evaluation. Phase two, around go-live, should test cut-over controls, parallel-run reconciliations, and access provisioning for the new platform. Phase three, after stabilization, should test operating effectiveness of change management and interface monitoring.

With four auditors and 1,100 hours, allocate hours explicitly: approximately 250 for scoping and vendor review, 350 for migration and interface testing, 300 for access and segregation of duties, and 200 for reporting and contingency. Use data analytics to compare legacy and SaaS user access and to reconcile record counts and balances, reducing manual sample sizes. Reuse prior-year testing only where controls are unchanged and evidence is current. Escalate early if the SOC 1 exceptions prevent reliance and additional substantive work exceeds the contingency. Report scope limitations to the audit committee before go-live, not after, so expectations are managed.