Skip to main content

The Seven-Step Model of Migration

Irrespective of the migration approach adopted, the Seven-step Model of Cloud Migration creates a more rational point of view towards the migration process and offers the ability to imbibe several best practices throughout the journey

Step 1: Assess
Cloud migration assessments are conducted to understand the complexities in the migration process at the code, design and architectural levels. The investment and the recurring costs are also evaluated along with gauging the tools, test cases, functionalities and other features related to the configuration.
Step 2: Isolate
The applications to be migrated to the cloud from the internal data center are freed of dependencies pertaining to the environment and the existing system. This step cuts a clearer picture about the complexity of the migration process.
Step 3: Map
Most organisations hold a detailed mapping of their environment with all the systems and applications. This information can be used to distinguish between the components that have to be moved to the cloud from the ones that should continue to reside in the data center.
Step 4: Re-architect
Migration to the cloud demands re-architecture of applications in most cases. This may result in the loss of certain functionalities, and this can be approximated by using relevant APIs.
Step 5: Augment
The applications are augmented to make them cloud-ready. Augmenting the applications is crucial to derive the best benefits of the cloud.
Step 6: Test
Right after the applications are augmented, they need to be tested for the new environment. The augmentation and migration strategies are validated at this step.
Step 7: Optimize
Based on the test results, the migration strategy is optimized for delivering the best ROI. A road map for leveraging the new cloud features is laid.

Comments

Post a Comment

thank you for visiting :)

Popular posts from this blog

Special Permissions in linux

The setuid permission on an executable file means that the command will run as the user owning the file, not as the user that ran the command. One example is the passwd command: [student@desktopX ~]$ ls -l /usr/bin/passwd -rw s r-xr-x. 1 root root 35504 Jul 16 2010 /usr/bin/passwd In a long listing, you can spot the setuid permissions by a lowercase s where you would normally expect the x (owner execute permissions) to be. If the owner does not have execute permissions, this will be replaced by an uppercase S . The special permission setgid on a directory means that files created in the directory will inherit their group ownership from the directory, rather than inheriting it from the creating user. This is commonly used on group collaborative directories to automatically change a file from the default private group to the shared group, or if files in a directory should be...
Post a Comment
Read more

Linux File System Permissions

Access to files by users are controlled by file permissions . The Linux file permissions system is simple but flexible, which makes it easy to understand and apply, yet able to handle most normal permission cases easily. Files have just three categories of user to which permissions apply. The file is owned by a user , normally the one who created the file. The file is also owned by a single group , usually the primary group of the user who created the file, but this can be changed. Different permissions can be set for the owning user, the owning group, and for all other users on the system that are not the user or a member of the owning group. The most specific permissions apply. So, user permissions override group permissions, which override other permissions. In the graphic that follows, joshua is a member of the groups joshua and web, while allison is a member of allison, wheel, and web. Whe...
Post a Comment
Read more

tag