Private and Public Cloud Project Considerations

Today we are going to discuss a few Private, and Public cloud project considerations leveraging cloud platforms such as Microsoft Azure and AWS.

After several years of migrating customers from on premise to public and private cloud solutions there are two thoughts that immediately come to mind that will typically determine the success/failure of a project 1) well vetted customer business needs (not wants) and 2) truly understanding a customer’s compute/network/storage requirements. 99% of the time customers do not truly understand or distinguish between their business needs vs. wants. The wants typically inflate the true cost of IT infrastructure and increase project scope/cost. From a project team perspective more challenges will present themselves if the team dynamic between application and infrastructure integrators is not fluid and synergistic.

Information technology infrastructure best practice approach to projects should be consistent whether it is on premise or hosted in the cloud. After experiencing over a hundred different migrations, whether it be email, ERP, data, and network the following core principles hold true. Requirements, requirements, requirements. Accept the fact that it will always be a delicate balance between the customers/business needs and wants. Someone very wise once told me early in my career that a “project’s wants are endless, but the needs are very few.” Cost ultimately helps drive the control associated with needs vs. wants.

What does this mean to the consumer? Questions that you should be asking are: What does this application we are putting in the cloud truly require from an infrastructure perspective? Are we adequately sizing the network on both ends? Do we truly understand the compute, transaction, and ultimately storage needs of the solution? Do we understand our Recovery Point Objective (RPO – maximum period in which data might be lost due to a major incident) and Recovery Time Objective (RTO – duration of time which a business process must be restored after a disaster) aassociated with the solution? Do we have sufficient use cases to ensure the user/business community can effectively negotiate the new platform being implemented? Ultimately the judges of the systems that are designed and implemented whether it be on premise or in the cloud are the end point clients/business users. No sense in moving to the cloud if the customer/business experience is slower and less efficient.

Questions and challenges like these beset most CIOs and Directors of Technology moving towards cloud. Navigating through these decisions can be somewhat daunting. Navigating through the different project challenges can present several challenges. Some of the following considerations you should present to your potential cloud provider/application integrator are as follows:

  • Project Team/Change/Configuration Management
    • Is each discipline adequately represented?
      • Management/Decision Makers
      • Application Integrator/Development
      • Client Support
      • Business Sponsor
      • IT Infrastructure/Cloud Provider
    • Has change control/configuration management been discussed?
      • Centralized document repository for configuration documentations
      • Centralized change management vehicle to track all changes made to the system?
      • Incident reporting system? What are the specifics of the work flow for issue tracking amongst all the project team members?
      • Change control board that will manage/maintain the system post implementation?
    • Internetworking:
      • How well versed is there staff on internetworking and the potentials that will beset a cloud project?
      • What type of connectivity does your application require?
      • What type of security as it relates to your application/business connectivity require?
      • Is your on premise network hardware adequate from a redundancy perspective?
    • Compute:
      • Are your application integrators/developers and infrastructure teams in sync? **This is one of the most critical elements to a successful cloud migration.**
      • Written requirements for your application as it pertains to cloud public/private platforms.
      • Licensing: have you mapped out what the software licensing changes that you may incur after moving to the cloud?
    • Application Presentation
      • How is the application/solution being presented to the end-point customer/business unit?
        • Remote Desktop Services
        • Citrix
        • Web Client
        • Full Client
        • Mobile Users
      • Use case development and implementation. Does it truly represent the customers/business units work flow and processes.
      • Locally/Geographically presentation considerations?


Microsoft Azure and AWS platforms offer scalable and cost effective solutions that help increase productivity and security. The landscape of how we access our systems is rapidly expanding. Companies are quickly learning the need for private, public, and hybrid cloud solutions is only going to exponentially increase in the near future. Make it easier on yourself. Explore and understand your options.

By |September 6th, 2016|Managed Services|Comments Off on Private and Public Cloud Project Considerations

Contact Us

Outer Edge Technology
485 Devon Park Drive, Suite 102
Wayne PA 19087
Phone: (866) 979-9605

Speak With a Business IT Expert Today

Call us at (866) 979-9605 or simply fill out the form below and we'll contact you shortly!

Your choice regarding cookies on this site

This website stores cookies on your computer. These cookies are used to collect information about how you interact with our website and allow us to remember you. We use this information in order to improve and customize your browsing experience and for analytics and metrics about our visitors both on this website and other media. To find out more about the cookies we use, see our Privacy Policy.

If you decline, your information won’t be tracked when you visit this website. A single cookie will be used in your browser to remember your preference not to be tracked.