Promoting a Half-Built Procurement Configuration from Sandbox to a Shared Test Pod
Vantage Industrial is 14 weeks into a Fusion Procurement implementation covering three business units. A systems integrator built the configuration in a sandbox and is now handing over to the customer's in-house team, which must promote it to test and then production. Two problems surfaced during handover. First, Sourcing and Supplier Portal were opted in at week 9, after the implementation project was created, and several tasks those offerings introduced were never picked up. Second, two analysts made changes directly in the test environment using Setup and Maintenance search rather than through the implementation project, so nobody can now tell which test values are deliberate configuration and which were experiments. The first configuration package exported from sandbox imported into test with warnings and roughly 60 percent of the expected setup tasks. Go-live is fixed for 1 October, and the test pod is shared with a payroll project that must not be disturbed.
1. The team proposes one full export from sandbox and one import into test, done over a weekend. Evaluate that approach and describe how you would sequence promotion instead.
Read the worked answer
Reject the single-shot approach. One full export and import is fast but unreviewable: when a large share of tasks land unexpectedly, you cannot tell which failure produced which symptom, and on a shared pod you have no cheap rollback.
Sequence by dependency, not by menu order. Enterprise structures and business units first, then the procurement business function and common procurement setup (document types, line types, approval groups, agents, categories), then Purchasing, Sourcing, Contracts and Supplier Portal. Later areas consume earlier ones as lookups, so importing them first produces missing-value errors that get misread as defects.
Match the environments before importing. The target must have the same offerings opted in, the same task list version, and the same business unit and ledger names. Run the compare utility first: it lists what is new, changed or missing between source and target, turning the import into a set of reviewed decisions instead of a surprise. Import does not delete, so decide object by object which side wins.
Import in iterations with a smoke test. One package per functional area, verified by a real transaction (requisition, negotiation, contract), and a written migration register for what packages cannot carry: suppliers, attachments, hierarchies, file-based reference data.
Freeze the environments during the window, and keep exploratory work in sandbox. That single discipline prevents the next drift.
2. Why is some of the analysts' direct test-environment setup missing from the package, and how do you close the gap without rebuilding everything?
Read the worked answer
Diagnose first. A configuration package exports the setup owned by the tasks in the implementation project's scope. If an analyst changed a task that was never added to the project, the change exists in the environment but is outside the export. That is the most likely cause here; the second most likely is setup that packages cannot carry at all - supplier records, attachments, hierarchies and file-based reference data usually move by spreadsheet or file-based import.
Close the gap in four moves. (1) Use the compare utility between sandbox and test to list every task whose setup differs. That list, not the project task list, is your true inventory. (2) Add the missing tasks to project scope in sandbox and re-export; the package now carries them. (3) For non-exportable data, build one repeatable import file per object and test it twice: into a clean pod and into the shared test pod. (4) Give the analysts a rule: changes go through the implementation project or into the migration register, never straight into search.
Reconcile rather than overwrite. Because import merges rather than deletes, decide per object whether sandbox or the existing test value is authoritative, and record the decision with a date and owner.
Do not rebuild. Full re-entry is the expensive option and usually introduces fresh errors in areas that were already correct.
3. Sourcing and Supplier Portal were opted in late, in sandbox only. What must happen in each environment before any package can be promoted, and what operational risks does the late opt-in create?
Read the worked answer
Treat the opt-in as a scope change, not a switch. Opting in an offering after the implementation project exists adds new task lists and typically seeds default configuration - negotiation styles, sourcing business functions, supplier registration defaults. Those defaults are easy to leave unexamined, and a package that references a style or configuration absent from the target will fail or leave a silent gap.
Order of work. In sandbox, confirm the opt-in is complete and refresh the implementation project so the new tasks appear in scope, then assign, configure, capture and re-export them. Opt in identically in test before importing, and refresh the task list there too. Never import a package into a target that lacks the offering: tasks outside scope are skipped with warnings, which is exactly the 60 percent symptom already observed.
Verify prerequisites, not just the task list: at least one active sourcing business function and a negotiation style the invited suppliers can use, supplier registration configuration and defaulting rules for the portal, and the approval routings both modules introduce.
Protect the shared pod. Schedule opt-in and import in a maintenance window with the payroll team informed, and smoke-test with a dummy negotiation and a dummy supplier registration.
Align production's opt-in date so all three environments share the same task list on go-live; otherwise every future promotion repeats this problem.