Upgrade Path to SQL 2008 (R2) and Windows Server 2008 R2

If you want to upgrade your SAP landscape to SQL 2008 (R2) and Windows Server 2008 R2 there are two possibilities. In this blog I will explain the differences between the two approaches and the advantages and disadvantages of both.

Since old SAP releases are not supported on Windows Server 2008 R2 and SQL Server 2008 (R2), you will need to upgrade your SAP software in order to use the new Microsoft releases. You can either upgrade your SAP software on your old hardware, old Windows Server and old SQL Server. This approach is described in chapter 1.

The other approach is to migrate to new hardware, new Windows and new SQL Server first. This approach is described in chapter 2.

Your landscape must not be older than R/3 4.6C. Please see chapter 3 for all relevant SAP Notes.

1. Conventional Upgrade Path

You first upgrade your SAP release to a newer SAP release that supports Windows Server 2008 R2 and SQL Server 2008 R2. Those are all SAP NetWeaver releases 7.00 and higher. Since 7.30 does not support Windows Server 2003 or SQL Server 2005, you cannot use this migration path if you want to upgrade to 7.30.

After the upgrade you perform a backup/restore system copy (system copy with database specific tools). Please read SAP Note 1152240 for prerequisites of your specific SAP release.

Example

Source		Target 1		Target 2
WAS 6.40	–>	ECC 6, BI 7.x, PI 7.1		ECC 6, BI 7.x, PI 7.1
SQL 2005		SQL 2005	–>	SQL 2008 R2
Windows Server 2003		Windows Server 2003	–>	Windows Server 2008 R2
Old Hardware		Old Hardware	–>	New Hardware

Advantages

• Supported for releases based on SAP NetWeaver 7.00, 7.01, 7.02, 7.10 and 7.11.

Disadvantages

• Upgrade path is not supported for 7.30 since SQL 2005 and Windows 2003 were de-supported for 7.30
• It will take much longer to upgrade those system on the old hardware (see my solution for a smaller downtime)

2. Quick Upgrade Path

A few months ago, I was working with SAP on a quick migration path for 4.6C, 6.20 and 6.40.

For this migration path you perform the DB specific system copy before you upgrade your SAP release. After the system copy, you are allowed to use your SAP system if you start the upgrade to the new release immediately after the system copy (see SAP Note 1476928 for more information).

The upgrade is performed on the new hardware, new Windows Server and SQL Server release and is therefore much quicker compared to your old landscape.

Example

Source		Target 1		Target 2
WAS 6.40		WAS 6.40	–>	ECC 6, BI 7.x, PI 7.1
SQL 2005	–>	SQL 2008 R2		SQL 2008 R2
Windows Server 2003	–>	Windows Server 2008 R2		Windows Server 2008 R2
Old Hardware	–>	New Hardware		New Hardware

Advantages

• You can run your upgrade on the new hardware.
• Supported for all target releases based on SAP NetWeaver 7.00 SR3, 7.01, 7.02, 7.10, 7.11 and 7.30

Disadvantages

• You must start the upgrade immediately after the system copy

3. General Notes

• The SAP Note for the Quick Upgrade path is 1476928
• If you’re running on 32-bit you probably want to change to 64-bit as part of the system copy (thanks to Clas for the hint)
• You must implement Support Packages for some systems to be supported on SQL2008 (R2) (see SAP Note 1076022) e.g. 7.00 SP14 or 7.10 SP8
• You must use a newer kernel for some releases (see SAP Note 1152240)
• If you upgrade your OS during a system copy , make sure that the kernel DVD already contains the newest kernel (see SAP Note 1152240- II SYSTEM COPY ON SQL Server 2008 (R2))

Comments

• Anonymous
  February 24, 2012
  Hello Sebastian, Thank you for your article. Right now I'm in the same situation to plan the upgrade of our SAP environment from 6.40/SQL2005/Win2k3 to 7.00/SQL2008R2/Win2k8R2. But there is one sentence in note 1443424 (Migration path to Win2008/MSSQL2008 for 4.6C and 6.20/6.40) which is confusing me: "The upgrade must be started immediately after the system migration.  >>>The system must not be used productively until you reach the end of the upgrade downtime.<<<" It is no problem to START the upgrade after the migration, but first we have the online phases where I could stay productive if I be on scenario 1. With scenario 2 I have to be offline for many more hours or days from the start of the upgrade. This doesn't make sense to me. Do you have a solution for that? Or did I something missed? Regards Holger

• Anonymous
  February 26, 2012
  Hello Holger, your assumption is correct. The old releases are not supported on SQL2008R2/Win2008R2 and are therefore not allowed to be used in production during the preprocessing phases. Scenario 2 has the advantages that the overall upgrade is much faster because I assume the you are using new hardware for the upgrade and you don't have to perform a system copy after your upgrade which also saves you a lot of time. If scenario 2 makes sense for you depends on the performance difference between your old and your new hardware. Best regards, Sebastian

• Anonymous
  November 20, 2012
  The comment has been removed