Cloud build, migration and operations services

IXC treats standing up a new cloud environment, moving an existing system, and running what comes after under one contract. When build and run sit with different firms, the first thing an incident costs is the wait for two sets of replies before anyone owns the cause.

The people who designed the environment carry on as the managed operations team; where an internal team takes over, the environment is handed across with the documentation. This deck maps how the six services split apart inside one project and where they come back together.

The work has three joints — design, migration, operations. Split all three across three firms and you get three sets of documents, and the gaps between them surface during an incident. With one team, the conditions agreed at design time become the decision rules written into the operations runbook.

Infrastructure build designs the network, servers, databases and deployment path a service runs on, then puts them in place. Migration confirms the dependencies between systems from real traffic records, groups them into waves, rehearses, and carries the cutover. Managed operations takes monitoring, incident response, patching, change and security review as an ownership grouped by service.

Cost reduction splits the bill by account, service and team to identify what drove spend up, then puts budget alerts and tagging rules into daily operations. A CDN answers repeatedly downloaded content from a point close to the user, while the web application firewall and DDoS defence stop malicious requests and volumetric traffic in front of the service. No one has to buy all six; starting with whichever hurts today still leaves the rest sitting on the same structure. Where to start is decided once the baseline exists.

The six do not require each other, but they share one asset inventory and one permission model. The account structure created during build becomes the access design for managed operations, and the metrics accumulated in operations become the baseline for cost work. The later a service joins, the less of the earlier documentation has to be produced again. Where the environment was built by another firm, the work starts instead with an inventory of assets and current permissions.

IXC holds a direct partnership with Akamai and works with public cloud through the Megazone partner network. Workload requirements come first; the provider and the services follow from that answer. A service with heavy overseas traffic and a service serving mostly domestic traffic get different answers, and where regulated data is involved the placement region is settled before the provider is.

Managed services carry a cost to leave, so how much stays on standard technology is agreed during design. The cloud account is either opened in the customer's name with administrative rights delegated, or held under a partner agreement where billing is handled on the customer's behalf. Either way, the end of a contract leaves the environment in place and only clears the permissions. Account ownership and the billing path are hard to change later, so they are settled before kickoff.

Within three weeks of kickoff, the current state of cost, performance, configuration and operational ownership is gathered by account into a baseline report. The target architecture and migration plan follow, reflecting business criticality and regulatory constraints, with the migration order and rollback conditions written into the same document.

After rehearsal the migration runs, observability, cost and incident response move into one operating model, and the migration record and operations runbook are handed over. Once the environment settles, operational metrics are reviewed monthly and the improvement backlog for the next quarter is prioritised together. The four deliverable names use the same words as the delivery items in the contract. Where the names differ, acceptance starts by arguing over what was received.

Each stage also states the condition for moving to the next. Without a baseline there is nothing to justify a target architecture, and without rollback conditions a rehearsal becomes a formality. The order is fixed so that each stage's deliverable is the next stage's input.

Night and holiday coverage is agreed at contract stage according to how critical the service is. Where operations are outsourced, the escalation path per severity is agreed in advance and incidents raised at night or on a holiday are received through the same procedure. Anything with customer impact is reported the moment it is received, progress is shared on a fixed interval, and the cause and prevention items follow in a written report.

Where downtime cannot be avoided, the rehearsal, the rollback conditions and the acceptable outage window are agreed first, and the change window is placed in the quietest traffic hours. What falls outside the scope is written in the same place: building new application code and developing business systems are not part of this practice, though the structure can be settled alongside whoever owns the development.

The question that comes up most in review is whether a team short on people can still start. Operational scope is taken over in stages rather than all at once, and repeated work moves into runbooks and scripts to lower the headcount it needs. Whether the choice locks the service to one provider is answered in the same conversation.