What is the difference between Pega inplace and out-of-place upgrade?

Every Pega upgrade has to answer one question before anything else: do you change the existing database in place, or do you build a new one next to it? The answer decides how much downtime you need, how you roll back, and how much risk lands on the production go-live.

Quick comparison

	In-place upgrade	Out-of-place upgrade
What happens to the database	The existing schema is modified by the upgrade scripts	A new schema is created and the existing data and rules are migrated into it
Downtime	Longer, the system is down while scripts run	Shorter, most work happens beside the live system
Rollback	Restore from a backup taken beforehand	Point back to the old schema, which is untouched
Infrastructure needed	Less	More: a second schema and often a second set of servers
Risk	Higher, mistakes hit live data	Lower, you can test the new schema first

How an in-place upgrade works

Take a full backup of the database and the application server.
Stop the application servers.
Run the upgrade scripts (or the installer) against the same schema so the Pega rule and data tables move to the new version.
Deploy the new Pega software and start the servers.
Run the post-upgrade steps: validate rules, run upgrade utilities, and fix any warnings.

It is simple and needs little extra hardware, which is why teams still use it for development and test environments.

How an out-of-place upgrade works

Stand up the new Pega version with its own new schema.
Migrate rules and the data you need from the old schema into the new one.
Test the application thoroughly against the new schema while production keeps running.
At cut-over, take a short outage, sync the final data, and switch users to the new environment.

If something goes wrong, the old environment is still there, so rollback is a matter of pointing users back at it.

A worked example

A bank has a claims application that must not be down for more than an hour on a Sunday. An in-place upgrade needs a four to six hour window because every rule and data table is rewritten on the live database. The team chooses out-of-place instead: build the new schema during the week, rehearse the migration twice in staging, then use the Sunday window only for the final data sync and the switch. If the smoke test fails, they send users back to the old system and try again the next weekend.

Which one should you choose?

Choose out-of-place for production, or whenever downtime and rollback matter. This is the safer and usually recommended route.
Choose in-place for lower environments, or small systems where a longer outage is acceptable and hardware is limited.
In both cases, rehearse the whole upgrade in a non-production copy first and record the timings.

Interview tip

Interviewers like to hear the trade-off rather than a definition: in-place is cheaper and simpler, out-of-place is safer and faster to cut over. Add one sentence about rollback and you will stand out. For the clean-up work that follows either type, read our post on the post-upgrade fixing process and browse the Upgrade label.