Shadow Landscape Specifications

[Former Member]

We've heard something along the way regarding building a shadow landscape during upgrades that would mirror our current landscape so that when we upgrade we can seamlessly cut over our system to the newest version. Would anyone have any information regarding this or where to find it?

[Matt_Fraser · Accepted solution]

Hi Connie,

I don't know that I would call it "seamless." This is just an optional practice during large upgrade projects to enable current production support activities to continue while executing the project. In a nutshell, you create copies of your DEV and QAS systems before upgrading them, thus creating a parallel development track leading to the same PRD target system.

For instance, if your original landscape has DEV->QAS->PRD, your new landscape will have DEV->QAS-> and DV1->QA1-> both with the same PRD at the end (a bit hard to 'draw' with just text in a comment). This way, when you upgrade DEV, and later QAS, you still have DV1 and QA1 on the original versions in case you need to create new transports for production support purposes before the upgrade project is complete.

Of course, this adds complexity to the project, as you must absolutely ensure that all your developers and configurators who do this repeat the exact same new development or configuration in the upgraded DEV system as well. So, the production support development workload is theoretically doubled. This way you can ensure that these configurations will still work in PRD after that system gets upgraded too.

Once the upgrade project is complete, you can get rid of the DV1 and QA1 systems, going back to the original three-system landscape.

Whether or not it's worth the extra administrative and support overhead to maintain the parallel landscape during the project is a decision to make at the start. It will depend on how long the project is expected to last, and how much of this kind of non-project-related configuration you anticipate needing to perform during the project.

There is also a concept of the "shadow system" during upgrades, but this isn't mirroring a landscape, it's just a tool within the upgrade process in a single system to minimize downtime. The use of such a shadow system is built into the upgrade tool, so it's not something you set out to do separately. From your mention of mirroring landscapes, I don't think this is what you are referring to.

Regards,

Matt

[Former Member · Accepted solution]

So there would only be one PRD system that all systems would end up with at the very end? The idea here is that we have our PRD system that is setup different than our DEV and QAS system so we're trying to replicate the environment when doing a seamless cut over to a new upgraded system. Our agency wants zero to minimum downtime when upgrading our PRD so I'm looking for option to do this. Would there be any best practices or documentation on this?

[Matt_Fraser · Accepted solution]

Yes, but if downtime-minimization is the goal, then a parallel landscape isn't really what you're looking for. There are a number of documents about minimizing downtime during upgrades in the space (switch to the Content tab, then on the left select the category Downtime Minimization). Probably the first one to start with is .

In this case it is the "shadow instance" that you're referring to. This isn't necessarily an entirely separate server, though it can be, depending on your resource requirements. Usually it's an additional instance created within your existing system, and most (but not quite all) of the upgrade is performed within it, and then at the end it is "switched" back to your regular system. The document goes into much more detail about this.

You will probably want to recreate your QAS system as a fresh copy of PRD so that you can practice this upgrade in a system that looks just like PRD. This will not only help iron out the procedure and any bugs or kinks, but give you an idea of the timing of everything, how long it will take. To seriously minimize downtime, you might even do this exercise a few times, refreshing and upgrading QAS over and over, until everything is as refined as it can be.

DEV is a different story. You can't really refresh it from PRD without losing all your change history, so this is not recommended. It's not impossible, though, and if it's seriously out of sync with PRD in terms of configuration, then you may need to consider starting fresh. It's a big step, though, and not taken lightly. Usually it's better to manually reconfigure DEV as much as possible to look like production. Either way, this is where your upgrade starts, including re-integrating any customizations into the new standard code.

[Former Member · Accepted solution]

I agree. I don't think that the parallel landscape is going to be the answer to our issue. I think what they are looking for is something that will mirror our landscape in a test environment. Might have to look into some cloud solutions.

[Reagan]

Check the upgrade guide for Dual Maintenance. Here is what the guide says.

Upgrade in an SAP System Group

Impact on Development

At a certain point in time during the upgrade, the development environment of the system that is upgraded is locked. Consider this development freeze in your project plan and inform your developers about it. To avoid the development system being unavailable during the upgrade, we recommend that you add a temporary copy of your development system to your system landscape. This temporary development system can supply your production system with emergency corrections or support a phased development go-live after you have upgraded the original development system. You then have to make any corrections in the original development system as well as in the temporary development system. Make sure that your developers are notified about the dual maintenance.

You basically create 2 new systems (D and Q) by copying the existing ones. There will be only one production system. If you are concerned about the downtime of the production system then you can make use of parallelism. Check SAP KBA 1616401 - Understanding parallelism during the Upgrades, EhPs and Support Packages implementations and also the presentation

There are other options like ZDTM and nZDTM for upgrades.

Cheers

RB

[Former Member]

Thank you so much for all of your helpful information. I work in an agency with only 4 analyst and myself as the only system admin so I'm not sure if that creating a parallel landscape is going to be the answer to our issue.

[Matt_Fraser]

That sounds familiar. We are just a bit larger than you. Our SAP support team is 12 people, including the manager, who doubles as a functional analyst as well, but we used to be much smaller. For a long time I was the only sysadmin, but I convinced one of the developers to "jump tracks" and now there are two of us. Still, there's more basis work than we can get done in the time frames the organization would like to see.

If the upgrade project is going to take a while, building a parallel landscape can be a valuable tool, but yes, it does mean extra work, especially for you. That's more about keeping production support operating while the project is underway than about reducing downtime for the production cutover, as we mentioned, but it's still worthwhile unless you can keep the project quite short.

You also could consider splitting the upgrade into two phases. This is quite common. Phase one would be a "technical-only" upgrade, in which you do the bare minimum amount of work to ensure that the same functionality you have today continues to work after the system is upgraded. If everyone focuses, you could probably get this phase done in two months: start with the DEV upgrade, spend a month unit-testing everything and making any necessary adjustments, upgrade QAS, spend a month regression/integration testing, then upgrade PRD. If you have a sandbox environment, upgrade that ahead of DEV for practice. Then phase two is the "functional upgrade," which isn't strictly speaking an upgrade, it's more about configuring and delivering new or improved functionalities that the organization hopes to achieve from the upgrade. In that part the workload shifts more to the analysts and less from you.

The danger with these "two-part" upgrade projects is that after the technical upgrade, sometimes the team gets distracted by other production support priorities and phase two never gets completed. Thus, the business goes through the hassle of the technical upgrade without receiving the benefits of the functional upgrade. If that happens, you will find you have less support for future upgrades, so you want to make sure phase two is treated as a priority.

However, by making the technical upgrade shorter, you reduce the need for parallel landscapes (indeed, probably eliminate the need, as it's a lot of administrative overhead).

For the production cutover, you also could potentially split that into different parts. For instance, if there are OS/DBMS patches included, you might do those during a separate maintenance window ahead of the application upgrade. Then, part of the upgrade can be run with the system online, so get as much of that done ahead of the downtime window as you can. You may find that you can get the downtime portion to fit within a normal "maintenance window."

[Former Member]

Thank you so much for the advice! I think this is a possible option I can discuss with my team. I think they really want to get a true simulation of our environment to test on so that our upgrades will be almost seamless. It's going to be a tough with a limited budget so I think I might have to get creative.