4 Steps to Lower Your Risk with a SQL Server 2014 Migration

Many IT professionals live by the maxim that if something isn’t broken, don’t fix it. This philosophy has its merits, but it can lead to continued use of software that has long been obsolete. For colleges and universities, this can be especially problematic. For example, many institutions are still operating SQL Server 2005 despite its end-of-life status.

Although Microsoft officially discontinues support for SQL Server 2005 on April 12, the software will continue to function. Given the cost and complexity of migrating to SQL Server 2014, some organizations may be tempted to maintain SQL Server 2005. Several factors, however, make this ill-advised.

The most important reason to migrate to a newer SQL Server version is that Microsoft will no longer provide security patches. Future users may discover security vulnerabilities, and hacker sites may document them, but users will have no way to patch their servers to address these weaknesses.

Institutions also should be aware that internal and external auditors can cite an officially recognized control failure based on continued reliance on outdated software. Consequences of such a citing could include suspension of certifications and required public notification of the institution’s inability to maintain its systems and protect student and faculty data. Given these risks, it is critical for institutions to immediately start planning a migration to SQL Server 2014.

Step 1: Inventory Your SQL Server Assets

The first step in the migration process is to compile a detailed inventory of your environment. You need to determine which servers have SQL Server 2005 installed (and which applications are using SQL Server 2005 databases) and how many SQL Server licenses you need.

Many tools are available to inventory IT resources, but it is smart to start with the Microsoft Assessment and Planning Toolkit (MAP). MAP includes a set of tools designed to assist with migrations to SQL Server 2014. These tools support discovery and inventory of SQL Server resources and provide detailed SQL-related reporting. They can even provide information about the hardware and operating systems on which SQL Server is currently running.

Step 2: Evaluate Your Existing Infrastructure

After the inventory, the next step is to evaluate your existing infrastructure with regard to its SQL Server 2014 readiness. Given SQL Server 2005’s age, you may find that your existing servers are not up to the job of running SQL Server 2014.

The SQL Server 2005 hardware requirements vary based on edition, architecture (32-bit versus 64-bit) and other factors. For the sake of comparison, SQL Server 2005 Enterprise Edition (32-bit) requires a Pentium III or higher processor, running at 600 megahertz or higher (1 gigahertz recommended), and 512 megabytes of RAM (1 gigabyte recommended). The 32-bit version SQL Server 2014, on the other hand, requires a 1GHz processor (2GHz recommended) and at least 1GB of RAM (4GB recommended). Those who want to run the 64-bit edition will need at least a Pentium IV processor running at 1.4GHz (2GHz recommended). The point is that the hardware currently running SQL Server 2005 may be inadequate for a newer version.

Operating system requirements also are important. Users can install SQL Server 2014 only on Windows Server 2008 or higher, in part because Windows Server 2003 has already reached its end of life and Microsoft no longer supports it.

Step 3: Choose Either an Upgrade or a Migration

One of the most important decisions in transitioning to SQL Server 2014 is whether to perform a migration or an in-place upgrade. An upgrade involves installing SQL Server 2014 on top of your existing SQL Server deployment, whereas a migration involves setting up new SQL Servers and migrating data to the new environment.

In most cases, a migration is preferable. Among the reasons:

• You can’t perform an in-place upgrade on top of SQL Server 2005. You would have to first upgrade to SQL Server 2008 and then to SQL Server 2014. A migration allows you to avoid this middle step.
• A migration lets you start with a clean deployment, rather than carrying over baggage from an older version of SQL Server (and possibly an older operating system).
• Many SQL Server 2005 deployments are running a 32-bit edition of SQL Server. You cannot switch to 64-bit as part of an in-place upgrade, because an upgrade forces your SQL Server to continue using the same architecture that it uses now.
• A migration is an excellent opportunity to virtualize your SQL servers if they currently run on physical hardware.

Step 4: Create a Migration Plan and Perform Lab Testing

The final step is to create a detailed migration plan and conduct lab testing to ensure that your plan works. You will need to answer these questions first:

• Will I perform an upgrade or a migration?
• Will I need to upgrade the operating system?
• Will I need any additional hardware?
• Will the transition to SQL Server 2014 impact my backup or anti-virus software?
• How will I test my applications to ensure they work with SQL Server 2014?
• How will I address any applications that are incompatible with SQL Server 2014?
• When will the transition process begin, and what IT or support resources will I need?
• Which servers will I upgrade first?

Transitioning from SQL Server 2005 to SQL Server 2014 can be a complex undertaking that requires extensive planning. Even so, continuing to run SQL Server 2005 after its end-of-life date poses serious risks. Accordingly, it is in an institution’s best interest to begin planning for the transition immediately.