Option 1 (In-place Upgrade) will have a longer production downtime as you would need to upgrade both rules and data schema during the downtime. Rules upgrade takes significantly longer time than data upgrade.
Option 2(out-of-place upgrade) allows you to upgrade rules while your production users continue to use the application. The real downtime is needed to point to upgraded rules schema and for data only upgrade. It will enable you to have a shorter code freeze window by having parallel development in order to be able to send production releases in current system and make upgrade fixes in another system. Merging the code may be another task. A longer code freeze may help you minimize the effort for parallel development and code merge tasks.
Option 1 is preferable if you can afford longer downtime and longer code freeze (as you wouldn’t be able to deploy code from upgraded 8.6 dev system to Pega 7.1.9 production system). Please note you may need more time to fix application upgrade issues if you’ve a complex application with a lot of customizations.
Option 2 is preferable if you’re willing to carry out additional steps to keep the downtime window and code freeze duration shorter.
Whatever option you choose, you should follow it in the lower environments as well as production because you will be better prepared for go-live.
@RameshSangili Thanks you for the details provided. What are the most common issues w.r.t application, we face post upgrade. Can you also provide details on any estimator tool available to calculate the efforts required for the migration.