AppZero Best Practices. Product Version 5.5.x

AppZero Best Practices Product Version 5.5.x

Table of Contents Processes and Methodology Critical Success Factors AppZero Migration Requirements Prerequisite Checklist Common Migration Questions and Answers Reference Materials

Processes and Methodologies

High Level Migration Methodology The AppZero toolset fits within typical migration methodologies found in most IT organizations and SI practices that, at a high level: Assess current environment by conducting workshops to determine application disposition, infrastructure and destination environment requirements (DC,MSP,CSP), and run server application discovery tools Plan the overall migration program based on information gathered in the assessment phase, establishing communication plans, physical source to destination mappings, and migration waves Migrate applications according to wave planning with resources allocated to perform the migration and test the application in the new destination before cutting production users over to new environment

Typical High Level Migration Methodology Assess Plan On Board Project Migrate Assess current state environment and perform Application Portfolio Analysis Server Application Discovery - Inspect IT Manifests - Automated Discovery Tools App Disposition Evaluation - App Decommission - Rationalization - Move to MSP/CSP App Dependencies - Server App Architecture - Database, Web Server, etc. Infrastructure Requirements - Compute - Storage - Network Plan all technical and business aspects of migration and attain sign-off Data Analysis - Coalesce Assessment Findings Plan Creation and Sign-off - Communication Plan - Risk Mitigation Plan - Project Plan - Migration Wave Plan Create Physical Mapping Artifacts - App Dependencies - App to OS/Server mapping - App to Storage mapping - Server Profile Best Practices - Technology and Industry Specific Validate prerequisites and execute migration, UAT and deployment according to plan Resource Allocation - Align resource with required SME during maintenance window - Assign Named Resources Validate Prerequisites - Source/Destination Credentials - Remote Source/Destination Access - Destination Provisioned Properly - Confirm Production Downtime Window Application Unit Test - Start services - Exercise App Features/Functions User Acceptance Testing - Executed according to plan

AppZero Migration Methodology The AppZero Migration Methodology orchestrates the details of a migration using the AppZero toolset, narrowing in on the specific tasks and details needed to execute a migration successfully. The methodology Maps to typical migration methodologies Can be adopted as-is or embedded within your own methodology Enables capture of key source application and environment facets Delivers a specification on how to provision destination properly Assigns ownership of tasks in the process and sets timelines

AppZero Migration Methodology WEEK 1 WEEK 2 Evaluation Initial call to evaluate apps and gather information about migration approach Checkpoint Finalize timeline/scope and assign AppZero and customer owners Discovery Inspect source environment using manual and automated methods Validation Validate prereqs were met on destination, install AppZero and test connectivity Migration Perform migration as planned, allowing for up to 2 migration iterations App/OS versions, storage,services,etc. Desired timeline Business constraints Test criteria Distribute prereq docs Review application maintenance window start and end Review timeline and scope Identify customer admin to provide credentials in each of the next steps Identify source machine Discovery Readiness Install and run AppZero Discovery tool PACE Manually navigate app environment Validate evaluation information collected Create final migration plan Install AppZero Install other components such as web deploy (if needed) Test source to destination connectivity for all components Gather any additional details Kickoff migration with AppZero tool Migrate into VAA Customer test to ensure migration meets success criteria Dissolve application from AppZero VAA to OS

AppZero Methodology Steps Described Evaluation is conducted as the initial conversation with key stakeholders to evaluate apps and source environments Checkpoint secures commitment of customer resources to own activities and have an active role in ensuring migration success Discovery provides the opportunity to inspect the source server and applications and plan migration steps in advance Validation ensures source and destination prerequisites have been met and product connectivity can be established Migration is executed with the benefit of all the planning and information gathered above

Critical Success Factors

Critical Success Factors Evaluation Ensure key stakeholders understand the methodology and rough timelines If not already introduced during the Evaluation call, set expectations why limited cycles from Sys Admin and App Owners will be needed Get confirmation that Sys Admin and App Owners will be available for Checkpoint call Distribute AppZero Prerequisite Checklist and Best Practices

Critical Success Factors Checkpoint Confirm sys admin (and app owner if necessary) possess server/app credentials and are knowledgeable enough to provide details required for successful migration and confirm availability to exercise app pre-dissolve and test post-dissolve Review next steps in the methodology with System Admin and App Owner, establish a timeline, and confirm availability

Critical Success Factors Discovery Conduct Discovery with the list of app and environment facets that need to be captured, including verifying those facets described in evaluation Ensure action items for sys admin are clearly called out and confirm acknowledgement of task and date action will be completed by Based on Discovery findings, provide a concise specification to the sys admin who will provision destination, specifying AppZero prerequisites

Critical Success Factors Validation Ensure destination server has been provisioned according to app requirements and AppZero prerequisites Install AppZero software on destination and test tether connectivity from destination to source For IIS migrations, install Web Deploy on source and destination and test connectivity

Critical Success Factors Migration Do not start AppZero migration if any AppZero prerequisite has not been met Plan migration duration to fit well within customer downtime window, with downtime ideally two times the estimation migration duration Ensure resources capable of exercising the application are available prior to dissolve, and resources who can user test the app after dissolve

AppZero Migration Requirements

AppZero Migration Requirements Local Administrator, Antivirus and Group Policy Local Administrator Account Credentials AppZero performs a series of low-level operations that only the local administrator account has the permission to do. On Vista, Windows Server 2008, Windows 7 and Server 2008 R2 (and beyond), as part of the User Account Control (UAC) functionality, users belonging to the Administrators group (other than the Default Administrator Account) are not assigned full administrative privileges when they log in. As a result, when members of the Administrators group run AppZero Administrative Console or the AppZero CLI (command-line interface) tools, VAA operations may appear to have succeeded when in reality they have silently failed. For this reason, we require use of the default Administrator user account for creating and managing VAAs on these platforms. A/V Software Removal Part of the AppZero approach is to inject components of our runtime into applications themselves. This can look malicious from an anti-virus software perspective. When attempts are made to disable the anti-virus software (instead of removing it completely) the A/V software has "hooks" in it to detect what it perceives as tampering and to re-start it's monitoring processes. The lack of the software on the destination server is the only assurance of a conflict-free state. The common A/V whitelist approach doesn t work since we don t know up front in the process all of the application assets that may look altered from the perspective of antivirus software. This is done in real-time as we migrate applications and their dependencies. It should be noted that once the application is migrated and dissolved the A/V software may be reinstalled and used. Group Policy Technology outside the scope of both the source and destination also can affect the quality of a migration. Group policy, for example, has the capability to interfere with some of these things. For example, a customer may uninstall anti-virus software the night or week before a migration only to find that Group Policy has installed it back when they return. It s difficult to pinpoint which technologies can affect the use of AppZero since there is an enormous amount of flexibility with how these tools are used. AppZero recommends that this document be reviewed with the team within your organization that is responsible for the security of the environment as a whole.

Prerequisite Checklist

Technical Migration Prerequisite AppZero specifies a handful of prerequisites be met within the environment prior to attempting migration. The next set of slides introduce those prerequisites and the justification for why they are required. A more detailed description can be found in the embedded document below. AppZero Migration Prep Checklist

Technical Migration Prerequisites Prerequisite Destination server(s) have adequate capacity to run the application VAA destination drive has enough space to contain the entire application Local built-in administrator un/pw on both destination and source Connectivity end-to-end from the destination machine to the source, on port 445 LAN Manager authentication level on the destination machine must be set to Send LM and NTLM Responses in order to connect successfully. No antivirus agents, or endpoint security agents running on the destination server, Justification Destination must be provisioned with equal or better cpu, storage, etc to accept source application Prior to dissolve, the VAA resides on a single drive and contains the entire application AppZero software requires local administrator to obtain all source applciation facets and install on destination All AppZero communication is facilitated on port 445 Required for tether connectivity Antivirus agents may prevent or severely slow down AppZero intercepts during tether

Technical Migration Prerequisites (Continued) Prerequisite Source and destination OS version is equal to or greater than the source OS Appzero software is installed on the destination machine. Appropriate ports are open on the destination server firewall so the application is reachable once it is migrated; for example, for SQL server this is typically port 1433 by default. Check if the source server has.net Framework version 4.0 or greater installed For IIS migrations, ensure Web Deploy is installed on both source and destination and that connectivity is established Justification AppZero will accommodate like to like and up-level migrations but does not support down-level AppZero is installed only on the destination server Application specific ports may require additional ports to facilitate communication multi-tier communications Required for IIS Migrations Required for IIS Migrations

Common Migration Questions & Answers

Common Migration Questions & Answers 1. How long of a maintenance window (down time) do I need? Duration of maintenance window = (application size / network bandwidth ) * 2 Where application size is the file size footprint of the application, as reported in the Add/Remove Programs applet in Control Panel network bandwidth is the effective throughput bandwidth between source and destination servers. The x2 factor allows for the fact that the bandwidth available on enterprise networks can be unpredictable due to other application traffic or network anomalies. If there are fixed business constraints on the maintenance window available for a given app, you need to adjust one of the above factors for example You can extract the application on a staging server closer to the source machine, to increase the network bandwidth available You can reduce the footprint of a large database server by moving the database files separately as files, or using database-specific tools. For more information on advanced techniques please consult other AppZero documentation or contact AppZero Customer Support. 2. What does it mean to exercise an application during VAA creation? To exercise an application, you perform the following steps: Start any Windows Services which have been added to the VAA, and any other server processes which constitute the application. Wait for them to complete the startup process and verify they started successfully. For user-facing applications, connect to the application using the application client or browser, and log in For many applications this is sufficient - during the tether process, AppZero uses heuristics to extract not only the files and registry entries explicitly loaded while exercising the app, but also any others that are adjacent to them in the file system structure, or related to them via implicit associations. For other applications you may need to execute additional application functionality to gather remaining parts of the application. Exercising the application should be performed by a user who is knowledgeable about the functionality and navigation of the application to ensure that all application components are addressed at runtime and migrated to the destination.

Common Migration Questions & Answers 3. When I can disconnect the tether from the production machine? After you ve enabled tether and docked the VAA, start the services or other processes which constitute the application, and verify that they started successfully. Log into the application and use the application interfaces to exercise the app. Once you ve done this, watch for activity in the Tether Monitor to subside, and wait until the Last Activity Time indicator shows the tether connection has been idle for 15 minutes or so. 4. When can I restart my production applications on my source server? Once you have undocked the VAA and disabled the tether connection, you can restart the application(s) on the source server. It s important to wait until tether is complete and disconnected, or some applications may fail to start if files are actively being transferred. 5. When should I plan to perform UAT? Most enterprises require a QA or UAT acceptance test before cutover to production use of a migrated application. The typical high-level process for executing UAT validation with AppZero is the following: Execute a trial migration of the application under a maintenance window, as described here and elsewhere, producing a VAA. Put the source application back in production Provision a test server which will host the UAT instance of the application; dissolve the VAA onto the server, restart the server and application, and execute the UAT test plan Once UAT acceptance testing is completed successfully, create a new VAA and re-execute the migration to capture the final state of the application.

Common Migration Questions & Answers 6. What do I do if something goes wrong? Start over with a new VAA on a clean destination machine. Some of the error conditions that may occur during a migration can leave the VAA in an inconsistent state: For example, if the network or the source machine fail during the tethering process, the content of a file or registry key retrieved may be incorrect. Or, if you entered a valid but incorrect service account user, the files retrieved would have the wrong access permissions. Once this invalid content is in the VAA, its presence prevents the differencing logic in the AppZero from retrieving the correct content even after you correct the error and resume the tether. While there are other error conditions that are recoverable if you correct them and resume, it s usually easier and more reliable to just treat all errors the same way and start over. 7. How do I go from UAT to production? In most cases the source application is put back in production after the initial maintenance window used to create the UAT instance of the application. As such it s likely the application state has changed, and the VAA used for UAT is no longer up to date. To extract an updated version of the application for final cutover, get a new maintenance window and repeat the migration process in a new VAA. While still under the maintenance window, dissolve the VAA onto the new destination. The new destination is now your production instance and you can decommission the original source server. I merged this answer into question 6, it s easier to understand if a single answer covers the whole process. 8. Should I run the application in the VAA or dissolve it? For a production application, once migrated, we recommend you dissolve the VAA so that it s provisioned permanently and runs natively. You should also dissolve the VAA when setting up the application for UAT, so that you have consistency between the UAT and Prod environments. 9. How do I move a 3-tier application? Is there an order? AppZero can move applications from a multi-tiered architecture in any order desired based on enterprise requirements or best practices. AppZero recommends that you proceed from the lowest layer up, that is, from the database to the client layer.

Common Migration Questions & Answers 10. How do I know if the application is compatible if I move it to a newer OS? Most Windows applications are binary-compatible with later versions of Windows. There will certainly be exceptions to this, but in practice while the number of Windows Server APIs and frameworks has grown over time, few if any have been removed, and the individual APIs have remained stable. Unless you have prior detailed knowledge of the internals of the application, the most cost-effective to assess binary compatibility with a later version of the OS is to perform a trial migration. 11. Will the application be supported once it is moved? Once the application is dissolved it runs natively and is identical to an original installation of the application. In our experience, moving the application does not impact vendor support policy, and the usual tools/practices used to diagnose and resolve application support issues are not affected. When moving an application to a newer version of the OS, the version of the application being moved may or may not be vendor-supported on the newer OS version. You may need to review the OS support matrix for the application or platform in question, and if necessary upgrade the application after the move. 12. Will I be able to upgrade my application once I migrate it? After you dissolve the application you can upgrade it using the upgrade tools available for the application. 13. How many licenses do I need to move a set of development, test, and production environments for a given application? If you move the 3 environments separately all using AppZero you need 3 licenses for the 3 separate source machines involved. Dev/Test/Prod rollout processes and requirements vary widely across enterprises and for specific applications: if in the existing processes for a given application the dev and test environments are created from the Prod environment, it may be an option to move only the Prod environment, then create Dev and Test from that in the usual way. If that is the case you would need 1 license as there would be only 1 source machine involved in AppZero migration.

Common Migration Questions & Answers 14. Can I separate applications that are on one machine to more than one machine? This is technically feasible but requires careful consideration of possible dependencies between the applications being separated. Contact AppZero or one of our SI Partners for services that can help with this evaluation 15. Can I consolidate different applications from many machines into one machine? This may be possible but it s difficult to assess whether two server applications can coexist on the same server, with or without AppZero. Contact AppZero or one of our SI Partners for services that can help with this evaluation 16. Can I consolidate the same application family from many machines into one machine? No. This is virtually guaranteed to create conflicts between multiple instances of the same application on the same server, and render all instances inoperable. 17. Can I move IIS Web Farms? You can move IIS Web Farm servers, but you will need your own expertise about IIS Web Farm Framework in order to set up WFF correctly on the destination environment prior to migration. In addition there is a specific procedure you need to use with AppZero during the migration contact AppZero Customer Support for the relevant tech note. 18. Can I move a SQL Server Failover Cluster using AppZero No. There are known issues with attempting to move Failover Clusters and it is not currently supported by AppZero

Reference Materials

Reference Materials Available at appzero.com Product Documentation FAQ AppZero User Guides and Support Resources http://docs.appzero.com/ Frequently asked questions about high level product capabilities http://www.appzero.com/faq Knowledge Base Near Real time publish of engineering issues, workarounds and patches Available Q1 2014

Available Training

AppZero Training Offerings AppZero offers evaluation training for those interested in becoming familiar with product interfaces and basic migration techniques and deep technical training for system engineers and SIs who need to become proficient just in advance of a AppZero migration projects Course Course Description Audience Type/Location Duration List Price Evaluation Training Introduction to AppZero migration interfaces and instructor led walk through of basic application migration techniques in a demo environment. System Engineers, Tech Leads, Practice Leads ILT/Virtual 90 mins Free* AppZero Basic Training** AppZero Advanced Training** Basic and Advanced Courses provides deep technical training for participants needing to become proficient with AppZero just in advance of performing migrations. Each class is made up of two training modules. Each module includes two hands on lab exercises in an environment provisioned for each student. A range of basic to complex migration techniques are covered, as well as troubleshooting techniques for commonly found anomalies in migration environments. The classes may be taken individually or combined into a one day class. Systems Engineers, Administrators and System Integrators Systems Engineers, Administrators and System Integrators * To prospective customers who qualify for an evaluation license ** Basic and Advanced Training may be consolidated into a one day class at a cost of $995 per student ILT with Hands on Lab/ Virtual or On-Site ILT with Hands on Lab/ Virtual or On-Site 4 hrs 4 hrs $595 per student $595 per student