Moving services to the cloud can be complex. We will walk the client through the process and agree a way forward as appropriate. In general, however, the following actions are generally required.
Requirements, signoff and quality gateways and processes are established. These generally cover defining Infrastructure, Platform, Services and Software needed and establish the correct set of technologies, e.g. ARM Templates, Terraform, to automate their implementation.
We work with you to define the environments, security boundaries and architecture needed to allow Development, test and rollout, along with the support needed internally to ensure success of the project. We will agree and scale each environment so they have enough resources within acceptable cost. This may mean working as part of your internal team to deploy, train or handover to.
We will work with you to assess impact to the business alongside the technology e.g. do we need to migrate out of hours? Can we deploy during the day? Do we need comms, training? We will help you be ready to move the system into Business As Usual, ensuring you have the support, either in house or externally, that you need.
We have assisted large public sector users to move services, software and content into the Cloud. This can include content repositories of over 10Tb, utilising techniques to ensure all data is moved safely, without data loss or compromising access.
We have moved and upgraded on premise software, such as DMSs or Tracking Databases, into the Cloud, helping clients understand the impact of doing this both on their technical staff and their users. Any system migration usually entails some sort of Azure infrastructure change and we both design and implement this on your systems, ensuring best practice is maintained.
By working with the business we identify realistic quantifiable functional and and non-functional, e.g. performance, availability, reliability and scalability requirements. We then formalise these requirements into repeatable tests. This gives confidence that the business understands what is being tested, why it is being tested and what the results mean so they can be sure of the level of quality the system actually supports. An example might be testing that loss of a number of servers does not impact availability of functionality and whilst it decreases the overall performance this is still above a known and acceptable threshold. Where data is being migrated as part of the process then mechanical reconciliation will be used to verify that the data has been migrated and modified correctly.