Some people think virtualizing a few servers in the data center constitutes a private cloud. For those people who understand it's a lot more, there's still a chain of decisions that need to be made and many bear traps to avoid along the way.

The private cloud allows automated provisioning of servers by end users. It's an automated infrastructure that runs mainly by policies and builds servers from prepared templates. It's metered to allow end-user chargeback to business units. It has rules and policies governing how long virtual servers may live, how they may be changed, and how their loads may be balanced across the cloud. In short, it puts a management layer of software over the virtualized servers and operates them in a highly automated, low touch, fashion.

Chris Greendale and Bruce Coughlin, two principals of Cloud Technology Partners, more frequently known as cloudTP, recently agreed to sit down in their Boston-area offices to discuss the pitfalls and decision points in getting to private cloud. CEO Greendale is the former founder of Cambridge Technology Partners and Breakaway Solutions. Coughlin, VP of cloud systems integration, is the former VP of portfolio and innovation at Siemens. Cloud Technology Partners works with clients such as Boston's State Street Bank on private cloud models.

Implementing a private cloud is a good idea in situations where the IT staff is determined to escape the repeated sinking of 70 percent or more of the budget into maintaining legacy systems. Moving more of the IT budget into new and custom business applications is one outcome of moving to the private cloud when the move is successfully executed. That will be jeopardized if the company doesn't already have a strong idea of its strategic direction prior to undertaking the move. If it does, then that sense of purpose can be used to drive IT purchases, staff development, and software development in the right direction.

Based on Greendale's and Coughlin's remarks on "transformational consulting," here are six steps to think about when you are on your way to the private cloud model:

1. Do you have an in-depth understanding of exactly what applications the company is currently running?

Are there legacy applications, running in the background for years, but still vital to the company? How do these applications connect you to your customers? "Once that's understood, we build a roadmap of where to start, and how to get there," said Coughlin.

2. In which architecture should each application live, legacy or cloud?

Should the application be a prime candidate to migrate into the new infrastructure? The latter architecture will be x86, predominantly virtualized infrastructure using Linux and Windows. How hard will it be to get the application there, if it's a mission-critical one? Can you get that Solaris, HP-UX, or AIX legacy procedural application to perform as a modular, services-oriented application under Linux? How is the application not cloud-ready now? How many obstacles, or "violations," as cloudTP calls them in its assessment process, need to be addressed to get it there?

3. What elements characterize the new architecture that you're considering for your private cloud?

Before any legacy application can be moved, the cloud architecture must be defined. What are the existing applications written in? What will they need to be written in for the cloud? CloudTP is frequently running into C, C++, Java, PowerBuilder, Visual Basic, and other .Net languages and occasionally Cobol applications that need to be migrated. In each case the migration agent needs to know: migrated to what defined architecture?

4. If you have established your target architecture, can you estimate the time and cost it will take to move legacy applications?

What if you outsourced the work? Would that be cheaper and yield satisfactory results? Knowing which overseas groups of programmers are good at one thing, not another, is a special aptitude. CloudTP or other outsourcing partners can manage that part of the process for you, for a price, of course. Some IT staffs will have outsourcing experience in-house as well.

5. What type of IT shop do you see yourself becoming?

"What is the outcome you are seeking?" said Greendale. Is the goal to end up as a proprietary shop with a key vendor or group of vendors acting as partners in providing integrated products, or perhaps you seek a more mixed-vendor and best-of-breed approach? If you want to escape lock-in, perhaps you'll want to use more open source. Do you have your own skilled developers who are able to meet deadlines and project budgets? Do you want to remain a custom shop that depends on in-house development?

6. Can you project your return on investment?

If you make the conversion, what will it cost and when will you get the payback? "In some cases, you'll see an ROI of one-year's time, and it becomes a no-brainer," said Greendale. Some of the payback comes when a balky application, changed so many times that one more change threatens to break existing parts, suddenly becomes more adaptable to the business in the cloud. Applications reorganized into modular, independent services are, by design, easier to adapt.

These six steps illustrate some of the key decision-making points in moving from legacy to private cloud. They by no means encapsulate the full process for getting there. For example, cloudTP's process includes 11 key points of cloud attributes, with sets of rules for each point that tell you whether you're meeting cloud principles. CloudTP said it has compiled 300 rules for testing the validity of an attempted conversion, as well as requirements to be met at the start of a project, and tests of quality assurance to determine whether they have been met at the end.

Charles Babcock is an editor-at-large for InformationWeek