[{"data":1,"prerenderedAt":465},["ShallowReactive",2],{"blog-\u002Fblog\u002Ffinance-systems-environment-strategy":3,"blog-surround-\u002Fblog\u002Ffinance-systems-environment-strategy":444,"blog-related-\u002Fblog\u002Ffinance-systems-environment-strategy":454},{"id":4,"title":5,"audience":6,"body":10,"cluster":408,"contentRole":409,"conversionGoal":409,"date":410,"description":411,"draft":412,"extension":413,"factCheckedAt":409,"faq":414,"featured":412,"language":409,"meta":424,"navigation":425,"order":426,"originalAsset":409,"path":427,"pillar":428,"primaryKeyword":429,"relatedProject":409,"releaseScope":409,"reviewCycle":430,"reviewStatus":431,"reviewedBy":432,"searchIntent":433,"seo":434,"sources":409,"stem":435,"tags":436,"type":442,"updated":409,"__hash__":443},"blog\u002Fblog\u002Ffinance-systems-environment-strategy.md","Finance Systems Environment Strategy: Dev to Prod",[7,8,9],"finance-transformation-lead","solution-architect","delivery-manager",{"type":11,"value":12,"toc":399},"minimark",[13,27,32,40,182,185,205,209,216,219,243,249,261,265,272,296,300,332,336,362,374,377],[14,15,16,20,21,26],"p",{},[17,18,19],"strong",{},"A finance-system rollout doesn't fail in Production — it fails because Production was the first place something was ever really tested."," The environment landscape is the least glamorous decision on a programme and one of the most consequential: get it right and every change earns its way to live through controlled gates, so go-live is boring. Get it wrong — config hand-keyed differently in each environment, tests run on data that looks nothing like reality, no production-like rehearsal — and the ",[22,23,25],"a",{"href":24},"\u002Fblog\u002Fcutover-and-go-live-for-finance-systems","cutover"," becomes the first honest test of the whole system, at the worst possible moment. This is how to design the landscape so it doesn't.",[28,29,31],"h2",{"id":30},"each-environment-has-one-job","Each environment has one job",[14,33,34,35,39],{},"The trap is thinking of environments as copies of each other. They're not — they're stages with distinct purposes, and the design work is deciding what each is ",[36,37,38],"em",{},"for"," and what lives in it.",[41,42,43,68],"table",{},[44,45,46],"thead",{},[47,48,49,53,56,59,62,65],"tr",{},[50,51,52],"th",{},"Environment",[50,54,55],{},"Purpose",[50,57,58],{},"Data",[50,60,61],{},"Integrations",[50,63,64],{},"Config",[50,66,67],{},"Owner",[69,70,71,94,116,138,160],"tbody",{},[47,72,73,79,82,85,88,91],{},[74,75,76],"td",{},[17,77,78],{},"Development",[74,80,81],{},"Build & configure",[74,83,84],{},"Minimal, synthetic",[74,86,87],{},"Stubbed \u002F mocked",[74,89,90],{},"Authored here",[74,92,93],{},"Build team",[47,95,96,101,104,107,110,113],{},[74,97,98],{},[17,99,100],{},"Test",[74,102,103],{},"Verify changes technically",[74,105,106],{},"Curated test data + known scenarios",[74,108,109],{},"Test endpoints of key integrations",[74,111,112],{},"Promoted from Dev",[74,114,115],{},"QA \u002F test lead",[47,117,118,123,126,129,132,135],{},[74,119,120],{},[17,121,122],{},"UAT",[74,124,125],{},"Business validates against real scenarios",[74,127,128],{},"Masked production-like data",[74,130,131],{},"Test\u002Fsimulated bank & system connections",[74,133,134],{},"Promoted from Test",[74,136,137],{},"Business owner",[47,139,140,145,148,151,154,157],{},[74,141,142],{},[17,143,144],{},"Pre-Prod",[74,146,147],{},"Dress rehearsal, performance, cutover practice",[74,149,150],{},"Full masked prod-like volume",[74,152,153],{},"Production-like (as close as safely possible)",[74,155,156],{},"Promoted, frozen",[74,158,159],{},"Cutover lead",[47,161,162,167,170,173,176,179],{},[74,163,164],{},[17,165,166],{},"Production",[74,168,169],{},"Live operation",[74,171,172],{},"Real",[74,174,175],{},"Live bank & system connections",[74,177,178],{},"Promoted, change-controlled",[74,180,181],{},"Service owner",[14,183,184],{},"Two design decisions carry most of the value:",[186,187,188,199],"ul",{},[189,190,191,194,195,198],"li",{},[17,192,193],{},"Integration realism climbs the chain."," Dev stubs integrations; Pre-Prod gets as close to real bank and system connections as is safe. The riskiest part of a finance system is where it touches banks and other systems — so the environment ",[36,196,197],{},"before"," Production must exercise those connections, not simulate them away.",[189,200,201,204],{},[17,202,203],{},"Data realism climbs too — but never becomes real too early."," Test data is curated and known; UAT and Pre-Prod use masked production-like data so validation meets real-world mess; only Production holds real sensitive values.",[28,206,208],{"id":207},"config-promotion-one-direction-owned-gates","Config promotion: one direction, owned gates",[14,210,211,212,215],{},"The single most damaging environment mistake is ",[17,213,214],{},"changing configuration directly in a higher environment"," — a \"quick fix\" in UAT, a tweak straight in Production. The moment you do, what you tested is no longer what's live, and every downstream assumption is void.",[14,217,218],{},"The discipline is simple to state and hard to hold:",[186,220,221,231,237],{},[189,222,223,226,227,230],{},[17,224,225],{},"Config is authored in Development"," and ",[17,228,229],{},"promoted forward"," — transported or deployed — through each environment in one direction.",[189,232,233,236],{},[17,234,235],{},"No changes in higher environments."," If UAT needs a fix, it's made in Dev and promoted up. Painful in the moment, decisive over the programme.",[189,238,239,242],{},[17,240,241],{},"Each promotion is an owned gate."," Someone approves that a change is ready to move up — not a free-for-all, not automatic.",[244,245,246],"pull-quote",{},[14,247,248],{},"What you test is exactly what you promote, and what you promote is exactly what goes live. Break that chain once — a fix keyed straight into Production — and every test you ran is now evidence about a system that no longer exists.",[14,250,251,252,256,257,260],{},"This is the environment counterpart to ",[22,253,255],{"href":254},"\u002Fblog\u002Fchange-management-for-finance-system-rollouts","change management",": the org side manages people through change; the environment side manages ",[36,258,259],{},"config"," through change, with the same insistence on control over convenience.",[28,262,264],{"id":263},"production-data-in-lower-environments-the-decision-to-own","Production data in lower environments: the decision to own",[14,266,267,268,271],{},"Realistic data is how testing finds what invented data can't — the counterparty with the odd name, the payment volume that breaks a batch window, the opening balance that doesn't tie. But production finance data is sensitive, and copying it down the chain wholesale is a data-protection incident waiting to happen. Make it an ",[17,269,270],{},"explicit, owned decision",", not an ad-hoc extract:",[186,273,274,280,290],{},[189,275,276,279],{},[17,277,278],{},"Mask or anonymise"," by default: representative structure and volume, without the real bank details, counterparties and amounts.",[189,281,282,285,286,289],{},[17,283,284],{},"Curate known scenarios"," alongside the masked bulk — the edge cases, negative paths and opening balances you ",[36,287,288],{},"want"," to test, which random data won't contain. Representative volume finds performance problems; curated scenarios find logic ones. You need both.",[189,291,292,295],{},[17,293,294],{},"Name who may copy production data, how it's masked, and where it may land."," No unmasked production extract reaches a lower environment without an owner and a reason.",[28,297,299],{"id":298},"common-failure-modes","Common failure modes",[186,301,302,308,314,320,326],{},[189,303,304,307],{},[17,305,306],{},"Config keyed per environment."," Hand-maintained config that drifts, so Production behaves like nothing you tested. The root cause of a startling share of go-live surprises.",[189,309,310,313],{},[17,311,312],{},"No production-like environment."," UAT sat on stubbed integrations, so the first real bank connection is attempted in Production during cutover.",[189,315,316,319],{},[17,317,318],{},"Real data everywhere."," Unmasked production data copied into open lower environments — a breach with a delay on it.",[189,321,322,325],{},[17,323,324],{},"Too many environments, none owned."," A sprawl of environments nobody's accountable for, so state is unknown and refreshes are chaos.",[189,327,328,331],{},[17,329,330],{},"UAT as a second system test."," The business \"validates\" by re-running technical checks instead of real end-to-end scenarios, so genuine business defects surface after go-live.",[28,333,335],{"id":334},"what-good-looks-like","What good looks like",[186,337,338,344,350,356],{},[189,339,340,343],{},[17,341,342],{},"Each environment has one purpose, one data profile, one owner"," — and you can say, for any environment, what's real and what isn't.",[189,345,346,349],{},[17,347,348],{},"Config flows one way through owned gates",", so what's live is exactly what was tested.",[189,351,352,355],{},[17,353,354],{},"Integration realism peaks in Pre-Prod",", where the cutover is rehearsed against production-like connections before it's run for real.",[189,357,358,361],{},[17,359,360],{},"Production data is masked by decision, not by luck",", with a named owner for every copy.",[14,363,364,365,368,369,373],{},"The environment strategy is invisible when it works and catastrophic when it doesn't — which is exactly why it's worth designing deliberately at the ",[36,366,367],{},"start"," of a programme, not assembling under pressure before UAT. Get the landscape right and every change earns its way to live through gates that caught the problems early. Leave it to improvisation and the ",[22,370,372],{"href":371},"\u002Fblog\u002Fwhy-tms-implementations-fail","reasons implementations fail"," will find you at cutover, where they cost the most to fix.",[375,376],"hr",{},[14,378,379],{},[36,380,381,382,386,387,226,390,393,394,398],{},"Part of the ",[22,383,385],{"href":384},"\u002Ftopics\u002Ffinance-systems-delivery","Finance Systems Delivery guide",". See also ",[22,388,389],{"href":24},"cutover & go-live for finance systems",[22,391,392],{"href":254},"change management for finance-system rollouts",". The ",[22,395,397],{"href":396},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":400,"searchDepth":401,"depth":401,"links":402},"",2,[403,404,405,406,407],{"id":30,"depth":401,"text":31},{"id":207,"depth":401,"text":208},{"id":263,"depth":401,"text":264},{"id":298,"depth":401,"text":299},{"id":334,"depth":401,"text":335},"execution",null,"2026-07-28","How to design the environment landscape for a finance-system rollout — Dev, Test, UAT, Pre-Prod, Prod — what data and integrations live where, how config is promoted, and who owns each gate.",false,"md",[415,418,421],{"question":416,"answer":417},"What environments do you need for a finance-system implementation?","Typically a chain of Development, Test, UAT, Pre-Production and Production — though the exact number depends on the platform and the risk. Development is where configuration and build happen; Test is where the team verifies changes technically; UAT is where the business validates against real scenarios; Pre-Production is a production-like environment for dress rehearsals, performance and cutover practice; Production is live. The point isn't the count — it's that each environment has a distinct purpose, a defined data and integration profile, and a clear owner, so a change earns its way up the chain one controlled promotion at a time.",{"question":419,"answer":420},"How should configuration be promoted between environments?","In one direction, through a controlled, repeatable process — never by re-keying config by hand in each environment. Configuration is built in Development and transported or deployed forward through the chain, so what's tested is exactly what goes live. The two disciplines that make this work are a strict no-changes-in-higher-environments rule (you don't 'quick fix' config directly in UAT or Production) and an owned promotion gate at each step, where someone approves that a change is ready to move up. Config that's hand-maintained per environment guarantees that Production behaves differently from everything you tested.",{"question":422,"answer":423},"Should you use production data in test environments?","Only with care, and usually masked. Realistic data makes testing meaningful — edge cases, volumes and messy real-world records that invented data never reproduces — but production finance data is sensitive (bank details, counterparties, payments), so copying it wholesale into lower environments creates a data-protection and security exposure. The common answer is masked or anonymised production data: representative structure and volume without the real sensitive values, plus a curated set of known scenarios and opening balances. Whatever the approach, who may copy production data, how it's masked, and where it may land must be an owned, explicit decision — not an ad-hoc extract.",{},true,6.5,"\u002Fblog\u002Ffinance-systems-environment-strategy","finance-systems-delivery","finance systems environment strategy","annual","reviewed","Tan Gravam","informational",{"title":5,"description":411},"blog\u002Ffinance-systems-environment-strategy",[437,438,439,440,441,25],"finance-systems","delivery","environments","config-management","testing","pattern","qyXrIf1gV7pKXg5A5rqdKVpljjXJUnhg5VOsVyvLz6s",[445,450],{"title":446,"path":447,"stem":448,"type":449,"language":409,"draft":412,"children":-1},"Electronic Bank Statement Processing in SAP","\u002Fblog\u002Felectronic-bank-statement-processing-in-sap","blog\u002Felectronic-bank-statement-processing-in-sap","text",{"title":451,"path":452,"stem":453,"type":449,"language":409,"draft":412,"children":-1},"Fit-Gap Analysis for Finance Systems","\u002Fblog\u002Ffit-gap-analysis-for-finance-systems","blog\u002Ffit-gap-analysis-for-finance-systems",[455,457,461],{"path":452,"title":451,"description":456},"A fit-gap analysis compares what a standard system does against what the business needs — fit, gap, or change the process. Avoiding the customization trap.",{"path":458,"title":459,"description":460},"\u002Fblog\u002Fsolution-design-and-blueprint-for-finance-systems","Solution Design and Blueprint for Finance Systems","How to turn agreed requirements into a signed solution design before build starts — and why skipping the blueprint is what quietly buys you months of rework.",{"path":462,"title":463,"description":464},"\u002Fblog\u002Fconfiguration-vs-customization-finance-systems","Configuration vs Customization in Finance Systems","Configuration fits your process using shipped settings; customization builds bespoke — a permanent liability paid at every upgrade.",1785237638627]