Balancing cost and risk migrating from windows server 2003 to the cloud

Balancing cost and risk: Migrating from Windows Server 2003 to the cloud Andrew Brust November 15, 2013 This report is underwritten by AppZero.

Balancing cost and risk: Migrating from Windows Server 2003 to the cloud 2

TABLE OF CONTENTS

Executive summary ................................................................................................................................... 3

Mitigation options ...................................................................................................................................... 5

Business-decision criteria ........................................................................................................................ 10

Costs ................................................................................................................................................... 10

Risk factors ......................................................................................................................................... 12

Key takeaways ........................................................................................................................................ 16

Appendix: Overview of Windows Server 2003’s end-of-support .............................................................. 18

About Andrew Brust ................................................................................................................................ 20

About Gigaom Research ......................................................................................................................... 20


Executive summary When no-cost support options for all editions of Windows Server 2003 and 2003 R2 come to an end on

July 14, 2015, organizations that have failed to take remedial action will be vulnerable to security

breaches when new flaws in their operating systems (OSes) are discovered and fixes are no longer readily

available. These challenges will be compounded by the lack of vendor-provided support. Companies still

running these products must analyze the impact of this event on their businesses carefully and make

decisions about what actions to take.

The many approaches for mitigating these risks range from taking no action to migrating all existing

systems that will be affected. Tools that assist with the migration process are available, and they even

target cloud-based hosting, which is a key IT initiative in many organizations.

This research report will help IT decision-makers evaluate the risks and costs associated with each

approach, and it will single out some items that are often overlooked.

Risks have associated costs.

We review several options for mitigation in this report. None of them is intended to stand alone.

Each organization will need to choose options that, when combined, will produce the optimal

solution.

For applications that reside in data centers certified to comply with quality standards, such SSAE

16 or ISO 27001, nonmigration options must be excluded from consideration.

Internally, labor resources are frequently considered zero-cost because they do not have direct

budget impact. But the allocation of these resources has associated opportunity costs from

delaying other projects, which will produce a ripple effect in the business.

When an application’s failure has an impact on revenue, it can quickly become a liability.

Organizations must make a full accounting of all costs associated with the existing state of their

systems, the migration costs, and the expected end states.

Any skill set that becomes rarified incurs a cost increase. As tech environments shift toward the

newer versions, proficiency with older versions fades away, so personnel who deal with them are

highly specialized, and they demand commensurate compensation.


Determining the importance of each application and tying it to the bottom line is a relatively easy

exercise for those in the revenue path, but estimating a worst-case outage has many variables, and

it’s unique to each business and application.

Organizations evaluating their mitigation options must understand that without a custom support

agreement -- and these are expensive -- no patches will be available for critical security

vulnerabilities discovered after public support has ended.

External factors, such as regulatory compliance requirements, may exclude mitigation options

that avoid or defer OS migration. Financial services and health care are two industries that have

specific constraints in this area.


Mitigation options Customers have at least seven approaches for addressing the impending end of extended support for

Windows Server 2003 on July 14, 2015. Each of these approaches has benefits and challenges.

Taking no specific action

Isolating servers running the old OS

Enlisting paid custom support

Retiring those assets using, or running, on the old OS

Manual migration to a newer version of Windows Server

Automated migration to a newer version of Windows Server

Migration to cloud-based infrastructure running a newer version of Windows Server

In this section, we enumerate and describe each approach. Readers must bear in mind that the first three

of the options listed above may not be acceptable for organizations in certain industries, due to regulatory

regimes with which those organizations must comply.


Choosing to take no action may seem contradictory, but it is a distinct form of response. A company’s IT

department must fully document and its leadership must acknowledge the potential scenarios,

particularly taking into account a security vulnerability being discovered or a system failure occurring.

Either of these two situations could call into question the decision of not having access to Microsoft

support.

Even so, after performing a careful analysis of the risks and costs associated with other approaches, some

customers may reach the conclusion that the risks do not outweigh the costs. For them, taking no specific

action may be the correct response.

Isolation

Isolation, which is a slightly modified form of taking no specific action, entails an organization isolating

the older systems in a portion of its network that is heavily fortified or even disconnected from the larger


company network and internet. This approach will largely address the problem of new security

vulnerabilities. It will not solve problems stemming from a lack of access to Microsoft support in a crisis.

Paid custom support from Microsoft

A review of Question 4 in the Microsoft Support Lifecycle Policy FAQs reveals that the end-of-support for

Windows Server 2003 is not what it seems. A customer may elect to enter into a custom agreement that

continues support for the covered product for as long as the customer is willing to pay for it.

Microsoft will not officially decide which products get custom support or what form that support will take

until about 12 months before the formal end-of-support date. Nonetheless, given that Microsoft does offer

custom support for Windows XP and Windows Server 2000, the probability is high that it will do the

same for Windows Server 2003.

Even so, custom support has a major impact on the cost side of the analysis, and, paradoxically, that

impact is likely to be greater on smaller organizations.

First, custom support is only offered to customers with active Premier support agreements.

Companies that don’t already have a Premier support agreement -- a group that includes many

smaller companies -- will incur a significant cost establishing one.

Second, beyond the cost of the prerequisite Premier support agreement, custom support

agreements themselves impose significant expense. Fees for a custom support agreement’s first

year are usually in the range of $200,000 and can compound, doubling or tripling annually.

Third, Microsoft will only sign custom support agreements with customers who have a fully

documented migration plan in place. So while Microsoft no longer has a policy of a hard stop on

support, it still has an interest in sun-setting support eventually, and a customer’s rigorous

migration plan helps ensure this will happen.

With the combination of a Premier support agreement and a custom support agreement, customers can

call for help when they need it, and they will have access to critical security patches. Security patches

rated as important and bug hotfixes are available for additional fees, which can cost $30,000 per patch in

the first year -- again, with annual escalations.

http://support.microsoft.com/gp/lifePolicy


Custom support is not a case of:


+ Writing a check

Business as usual

The program is designed to provide bridge support for mission critical systems on a path to remediation.

It can buy time, but it is not a permanent solution.

Retirement

The final option that does not involve migration to a different version of the OS is fully retiring

applications. This can be beneficial on its own or in conjunction with other options.

Periodically, enterprises assess their application portfolios to improve the support and functionality of

key business applications. Often, they determine that certain applications have reached the end of their

useful lives and can be retired without business impact. Many applications running on Windows Server

2003 may meet this criterion.

While retiring all servers running Windows Server 2003 within an organization is unlikely, retiring as

many as possible offers benefits. If the organization has chosen the “take no specific action” or “isolation”

options, the risks are incrementally reduced for each server retired. If an organization has chosen the

“custom support” route, retiring as many servers as possible has a cost benefit, because custom support

agreements have price tiers based on the number of devices covered.

Manual migration

For some applications, manual migration to a server running a newer version of Windows Server may be

a viable option. A variety of events, such as hardware failure or hardware end-of-life, might have forced

such migration previously, because the new hardware might have been configured with a newer version of

the OS.

Many applications require effort beyond simple reinstallation for a successful migration. Revisiting the

development process may be necessary for application dependencies on OS functionality in Windows

Server 2003 that has changed, been deprecated, or removed in later versions.

Developer modifications might only be an option for internally developed applications. Third-party

application developers might be unwilling to reopen development for an application, and they may have


many valid business reasons for taking such a position. Those developers may also be unavailable, as

independent software developers may cease operation or become acquired over the years.

Even assuming that the technical challenges can be solved, the human resources’ costs for manual

migration can be high. Customers must commit either internal or external resources -- minimally in

operations -- for the actual migration. Also, developer resources may be required to remediate custom

code.

Keep in mind, though, that, as with the “retirement” approach, even a partial manual migration effort

improves the risk and cost factors of the “taking no specific action,” “isolation,” and “custom support”

options.

Automated migration

Another approach involves using specialized tools that enable encapsulation of applications on Windows

Server 2003 and migrating the applications to newer versions of Windows Server. Such tools can work

well, because in many scenarios, components of an application are well known and well behaved, with

reasonable OS dependencies.

Even so, some of the more complex enterprise applications will not lend themselves to this technique.

Applications like SharePoint, for example, may have multiple subsystems, and they may depend on the

OS to support them and coordinate between them. Automated migration tools must determine all OS

dependencies, although this can become impractical for applications that go beyond a certain level of

complexity.

Automated migration tools reduce the need for other forms of mitigation, but they do not eliminate them.

But, where these tools do work, their costs, and relicensing costs on the target systems must also be

accounted for. The cost for human resources applies as well, although they should be substantially lower

for automated migration than for manual migration.

Tool-based migrations can reduce the aggregate cost of manual migrations, because fewer servers will

require manual migration. Depending on the number of servers, the tooling cost may be justified clearly

and quickly. Tool-based migrations may even work when manual migration is not possible (for example,

when it is not possible to locate an application’s installation media). Each migrated server improves the

risk and cost factors of the nonmigration methods.


Manual and automated migration targeting a cloud host

A company that has decided to exercise “manual migration,” “automated migration,” or both has a variety

of options for where the migrated applications can reside:

Internal virtual or physical machines

Hosted virtual or physical machines

Cloud-based virtual machines

The availability of cloud-hosted virtual machines provides an additional cost-optimization factor.

Eliminating the physical servers in these scenarios will result in reduced capital expenditures, as no

hardware is purchased. Savings in operational expenditures will be realized as well, for example in terms

of power, real estate, etc. Process improvements derived from the simplified management tools of a cloud

host yield additional improvements.

Decision criteria vary greatly, depending on an organization’s specific business needs and size. Large

companies are less sensitive to capital expense and overall data center utilization because they are

committed to maintaining data centers for the foreseeable future. So, the incremental cost improvement

that might be gained by moving servers to a cloud environment might have less impact than it would for a

smaller organization that either does not have a data center or has a plan to eliminate existing facilities.

Likewise, companies that are engaged in a traditional hosting arrangement for their data center needs,

with a multiyear contract, are less likely to be swayed to transition to cloud-based hosting as that

approach adds vendors to their environment without a substantive reduction in the existing cost model.

For firms that are actively looking to transform their existing environment to a cloud-based model, the

migration of Windows Server 2003-based applications represents an opportunity to move a significant

block of legacy functionality to the cloud.

The enabling factors are independent of the migration itself. The cloud vendor must still meet the service-

level agreements (SLA) of the business, and third-party software vendors must be willing to support their

products in a cloud environment.

The automated migration model has additional cost benefits. Many of the tools available are already

cloud-aware, eliminating the effort required to set up a new environment, which is likely a significant cost

component of the project. Both the financial and schedule factors are improved by targeting a known

environment.


Business-decision criteria The business leaders who must ultimately approve a migration plan will look at two main criteria: cost

and risk. Despite many details to consider, costs are relatively straightforward to analyze. Risks often

manifest themselves as indirect costs. A system failure that affects revenue can quickly move a system

from a benefit to a liability. Any opportunity to quantify risk will help executive leadership make a fully

informed decision.

Costs

Accounting for the costs associated with the existing state of the system, the migration costs, and the

expected end state are critical. One frequent characteristic of migration projects is the difficulty

demonstrating value outside of the IT constituency. The business perspective is often that migrations

consume money, and, ultimately, functionality remains the same.

With a hard deadline on the end-of-support for Windows Server 2003 looming, the costs of migrating --

as well as the hidden costs of not migrating -- must be called out and explained. Migration costs include

human resources requirements, and not migrating include costs for support contracts with escalating

price models. Following are some additional costs.

Expertise in aging technology

Administrating OSs, which are complex entities, requires detailed knowledge and specialized skill sets.

This is even more so for older versions of Windows Server since, as the product has matured, Microsoft

has worked diligently to make it easier and more flexible to operate. As tech environments shift toward

the newer versions -- which can be significantly different to administrate -- and IT pros spend the

majority of their time with them, proficiency with older versions fades away. Any skill set that becomes

rarified incurs a cost increase.

Hardware

The newer versions of Windows Server require 64-bit CPUs and specific virtualization features. Windows

Server 2003-vintage hardware is thus often incompatible, requiring the acquisition of new hardware for

the OS migration.


Software

What effort and resources are required to modify existing software so that it can run in the new

environment?

While Microsoft invests considerable effort in backward compatibility, newer and older versions

of Windows Server have significant differences.

The migration from 32-bit to 64-bit hardware will require full regression testing to assure stability.

The human resources needed to perform this testing and any required modifications can incur

significant cost.

Licenses

Windows Server. If the Windows Server 2003 licenses are under Software Assurance, then they

can be upgraded to newer versions at no additional cost. If not, new licenses must be acquired.

Third-party components. If the licenses for third-party applications are transferable to newer

environments, this will avoid further costs in this area. If not, new licenses will be needed, at

additional cost.

Migration effort

All of the mitigation methods described in this report require human resources, either internal or external.

The cost of each manifests in different ways.

Internal resources are full-time employees and contract workers. They work on the highest priority

projects. Three pools that are required for migration projects are system administrators, developers, and

project managers. Other groups that may be needed are system architects and engineers, along with

application architects and developers, depending on the complexity of the issues encountered. Most

companies keep their employees fully utilized, so allocating them to migration projects will impact

progress on other projects and activities that may be key to the company’s business. The cost of using

internal resources for a mitigation project is an opportunity cost, given other projects are not moving

forward while the mitigation is being executed.

External contracted resources can provide all of the resources needed for a mitigation project. The benefit

is incurring only temporary labor costs, those associated with the migration project. The downside is that

much of the detailed knowledge gained during the migration will not be retained internally. One solution

to this challenge is to combine a few internal resources with the migration team.


Note that even “taking no specific action” has costs, although that approach pushes the costs out in time

and makes them somewhat unpredictable.

Tooling

The net cost savings of the automated migration approaches is moderated by the cost of the migration

tools. The more applications that can be migrated in an automated fashion, the more cost-effective this

approach becomes. For large organizations that may be faced with migrating thousands of applications,

tooling might be the best way to address the size and scale of the migration effort they face.

Custom support

A Microsoft custom support agreement is a complex part of the cost model. It is tempting to view custom

support as a means of converting operational risk to a financial impact, but such an analysis would be

flawed. Custom support is merely Microsoft’s offering to its customers who cannot retire their Windows

Server 2003 systems before July 14, 2015, but who will nonetheless retire them eventually.

Risk factors

Mission-critical rating

Each system must be ranked by its importance to the healthy operation of the company’s business. It is

possible to tie any system to the bottom line. If the system in question becomes unavailable, the financial

impact must be specified.

Determining this impact by quantifying revenue flowing through the system per unit of time is a relatively

easy exercise for systems that lie in the revenue path. Parts of this determination are less straightforward,

however. For example, the estimate for a worst-case outage has many variables and is unique to each

business and system.

Productivity systems present a greater challenge. Estimating the financial value of a system that makes

people more efficient is more complex than a similar calculation for a system that produces revenue (or

prevents lost revenue) directly.

With the estimated cost of an outage established, the importance of the system to the overall business can

be ranked. Formulating the estimate is a good exercise, as it allows an organization to cull systems that

are providing insufficient value.


Dependencies

Many systems -- for example, a database server -- provide support for the functions performed by other

systems. Sometimes, when dependencies are not obvious, a system may be judged non-critical when a

critical system may depend on it.

Security

Will the black-hat community see systems running de-supported OSes as compelling targets? A

significant factor will be how many Windows Server 2003 systems -- currently estimated at more than 10

million -- will still be in service come July 14, 2015. The fewer the number of customers who migrate, the

greater this risk factor becomes.

Many security exploits do not discriminate on the OS version. Some vulnerability discovered in the later

versions of Windows Server is likely to be tied to code that originated in Windows Server 2003. Attacks

based on these flaws simply target every server regardless of version. Unpatched Windows Server 2003

systems will be open to exploit, possibly causing outages and incurring associated risks.

No support

End-of-support quite literally means that when no custom support agreement is in place, no support will

be available beyond what Microsoft may publish to its knowledge base and what various online

communities are able to produce. Organizations evaluating their mitigation options must understand

what pieces will be missing. Without a custom support agreement, no patches will be available for critical

security vulnerabilities discovered after public support has ended, although all publicly available patches

made previously available will remain so.

Without a custom support agreement, there are no patches available for important security vulnerabilities

or non-security related hotfixes. With a custom support agreement, such patches or hotfixes are available,

but hefty fees apply.

Customers with a Premier support contract but without a Custom Support agreement will not be able to

obtain support from Microsoft support engineers. Any enterprise large enough to carry Premier support

should pay special attention to this particular aspect of the post-end-of-support period.

Assuming the likelihood of a crisis is low, and in the unlikely event of such a crisis, an organization will be

tempted to think it’s fully capable of fending for itself. The old military adage, “No battle plan survives

engagement with the enemy,” applies to a critical server down situation. No company would want its IT

“troops” on the front lines without support.


Politics

A key part of any plan addressing the end-of-support event is two what-if scenarios: what if something

bad happens, and what if it doesn’t? The IT executives who submit a mitigation plan for budgetary

approval are, in effect, telling executives that the plan they’re suggesting is the best one for protecting the

business.

Two possible outcomes could call these plans into question:

In the first scenario, a crisis occurs. For example, a company may view a zero-day security exploit,

with media driving its intensity, as a crisis. Another example is failure of a mission critical server

that has an impact on the operation of the business. For plans that include Windows Server 2003

in the environment, IT’s ability to resolve the crisis in a timely and normal manner will be the

plan’s ultimate test. Any barriers to resolution that could have been incorporated into the plan will

be highlighted, and the entire plan will be scrutinized.

In the second scenario, crises don’t occur -- or none occurs that has a major business impact.

Meanwhile, other IT initiatives were deferred to fund the migration. In this scenario, will the large

spend on Windows Server 2003 end-of-support mitigation be defensible?

Fading expertise

Mastery of a skill set requires ongoing application. This is certainly true of system administration skills

for an OS, especially when the skills required to do a given task change for later versions. The nature of an

IT environment is evolutionary. New deployments are made on newer technologies. Older technology

implementations are upgraded or retired. Eventually the staff no longer needs to exercise its skills on the

older technology regularly, and its proficiency fades. This can happen even if the skill set is maintained.

Hampered proficiency slows responses and reduces readiness for a crisis, which will likely translate into

further costs.

Software

Before choosing a migration method, a customer must ascertain whether the new environment will

support and make its software applications available -- or if the old one will continue to support them.

Often, new versions of applications are designed for newer OSs, and the old versions are phased out.

Trying to mix old and new, in whatever permutation, can create liabilities. Customers should question

third-party software vendors about their policies.


Software products from vertical vendors, such as Microsoft, present special challenges to the application-

OS pairing. Not all components of an application stack are on the same lifecycle. Many Windows Server

2003 servers, for example, may be running SQL Server 2005, a product that does not exit support until

2016. Migrating the OS now, but sticking with the same version of SQL Server means more costs later.

But updating SQL Server will add to the complexity of the project, and thus to the risk factors.

If the installed components will be supported longer than the OS version will, keeping them in place and

addressing those end-of-support issues when they get closer is an approach that serves to reduce the

complexity, cost, and risk of the current mitigation project. This approach requires that all decision-

makers be informed of the need for another project later.

Do the math

The final step in selecting an approach is building a spreadsheet that includes all of the costs that have

been discovered in the analysis process. The complexity of this exercise lies in assigning costs to risk

factors, a critical step for balancing the risks with the costs. Avoiding a large quantitative cost figure, with

a list of risk factors described only in qualitative terms, is important as it may unduly marginalize the risk

factors.

The spreadsheet will have three major dimensions: method, time, and costs. IT decision-makers will need

to see more of the detail whereas business decision-makers may only need to see a simple analysis. At a

minimum, the spreadsheet should offer at least two approaches. The consideration of several approaches

may not guarantee full appreciation of the cost and risk factors, but it will promote careful analysis

instead of a detached, rubber-stamp decree.


Key takeaways Windows Server 2003 will reach the end of its formal support lifecycle on July 14, 2015. Companies still

using it must prepare for this event.

Seven mitigation approaches are available:

1. Taking No Specific Action

2. Isolation

3. Custom Support Agreement from Microsoft

4. Retirement

5. Manual Migration

6. Automated Migration

7. Cloud Migration (Manual or Automated)

No single approach will likely meet the needs of an organization. A detailed analysis of each

affected system is required for informed recommendations about the combinations of approaches.

Nonmigration approaches, including the taking no specific action, isolation, and paid custom

support from Microsoft, may not be permitted, depending on the industry in which the

organization operates or the certifications under which the data center operates.

Organizations must consider a variety of cost and risk factors to establish a baseline for the

complete analysis. Some factors do not apply to all organizations. The first step in the analysis is

deriving the full list of costs and risks that are meaningful to the company, the individuals who

will make decisions about migration, and those who will have to function in the environment that

results from those decisions.

Customers must build a spreadsheet model that can inform the decision process and present

recommendations to non-technical executives who have short- and long-term stakes in the

decision.


With more than 10 million Windows Server 2003 instances still in production today, the formal

end-of-support for the product is a major event. Although lacking the drama of Y2K mediation at

the end of the last millennium, the Windows Server 2003 event touches on all of the same issues,

including large mitigation expenses and soft risk factors.

As with Y2K, the Windows Server 2003 end-of-support event is significant, but with proper

planning can be managed smoothly, eliminating disruption. Careful consideration of the costs and

risks involved will enable IT personnel to choose the mitigation methods most appropriate for the

organization.


Appendix: Overview of Windows Server 2003’s end-of-support In 2008, Microsoft committed to a formal support lifecycle for its products, rather than letting product

groups determine policy on a case-by-case basis. This change was necessary to help customers plan for

each product’s end-of-support, a lesson Microsoft learned when Windows NT 4.0 reached the end of its

15-year lifecycle, and customers were unable to execute their short-term migration plans effectively. The

result was a significant outcry from the market.

When Microsoft studied industry norms for lifecycle policies, it learned it was the only major enterprise

software vendor that had a hard stop on support for a major product. This, coupled with a customer

requirement for a consistent policy across all products, resulted in the Microsoft Support Lifecycle Policy.

Its key points are:

Microsoft will provide a minimum of five years mainstream support, meaning that a product will

be supported until:

o Five years after its release

or

o Two years after release of the product’s subsequent version

The company will provide five additional years of extended support, after mainstream support

ends.

Public end-of-support for a product will therefore occur no sooner than 10 years after its release,

with the full duration determined by the variable duration of mainstream support, described

above.

Details of what is provided in each support phase must be supplied.

Customers must keep software updated to the latest service pack levels.

http://support.microsoft.com/lifecycle


While this policy addresses issues of consistency and predictability, the issue of a hard stop for

support must be addressed as well. Microsoft accommodates customers’ needs for ongoing

support with custom support agreements, which are defined on a per-product basis at the end of a

product’s public support lifecycle. For example, Windows 2000 is in the custom support phase

now, Windows XP is less than 12 months away from it, and details of its custom support

agreement are being shared with eligible customers now. Details for Windows Server 2003

custom support agreements will be available roughly 12 months prior to the public end-of-support.

Windows Server 2003’s lifecycle is tied to the May 2008 release date of Windows Server 2008, the

subsequent version of the product. Adding two years to Server 2008’s release date (per the second

option in the mainstream support formula) brought Microsoft to dictate that mainstream support

for Windows Server 2003 would end on July 13, 2010, and extended support will end on July 14,

2015. (Microsoft “rounded” the month up from May to July.)


About Andrew Brust Andrew Brust is the founder and CEO of Blue Badge Insights, which provides analyst, strategy, and

advisory services for Microsoft customers and partners. He covers big data for ZDNet, and he is a

columnist for Visual Studio Magazine. In addition, he is involved with the Microsoft developer

community, especially in New York City.

About Gigaom Research Gigaom Research gives you insider access to expert industry insights on emerging markets. Focused on

delivering highly relevant and timely research to the people who need it most, our analyses, reports, and

original research come from the most respected voices in the industry. Whether you’re beginning to learn

about a new market or are an industry insider, Gigaom Research addresses the need for relevant,

illuminating insights into the industry’s most dynamic markets.

Visit us at: research.gigaom.com.

© 2013 Giga Omni Media, Inc. All Rights Reserved. This publication may be used only as expressly permitted by license from Gigaom and may not be accessed, used, copied, distributed, published, sold, publicly displayed, or otherwise exploited without the express prior written permission of Gigaom. For licensing information, please contact us.

http://pro.gigaom.com/

mailto:[email protected]

Balancing cost and risk migrating from windows server 2003 to the cloud

Technology

Transcript of Balancing cost and risk migrating from windows server 2003 to the cloud