Know what you have before you move it
For cloud infrastructure and migration, we would design the environment your systems run in, build it, and move them into it. Scope can include servers, networks, identity, hosting, capacity and backups, and the design would be agreed before anything moves.
- What it covers
- Design, build and migration
- Starting point
- An inventory of what runs today
- Platform choice
- Decided during design, not assumed
- Ownership
- The accounts it runs on are yours
- Not included
- Day-to-day running, which is Managed IT
What it solves
The situations this is for
Infrastructure that grew piece by piece
Servers, mailboxes and storage were each added to solve something. Nobody designed the result, and no single person can describe all of it.
Migrations that stall at the edges
The big systems move on schedule. What keeps the project open is usually something small: a shared drive nobody owns, or a service account with a lost password. Then there is the one application with a server name written into it.
A cloud bill sized by guesswork
Cloud resources were set at a number that felt safe at the time. The bill now reflects the guess rather than the workload, and nobody wants to be the person who shrinks it.
Backups nobody has tested
The backup jobs run and report success. Nobody has checked what they would actually restore, in what order, or who has the access to do it.
Scope
What the scope can include
Design and planning
- A review of what actually runs today
- Target environment and cloud architecture design
- Hosting and platform selection
- Cloud resource and capacity planning
Build and migration
- Server, network and identity setup
- Separate development, test and production environments
- Microsoft 365 mailbox, file and identity moves
- Server and application migration to cloud or new hosting
- Cutover order, rollback plan and checks after the move
Backup and recovery planning
- Backup design and configuration
- Restore testing against agreed scenarios
- Recovery plans for defined failure cases
Scenarios
What this could look like
Servers reaching end of life
For example, a business's servers are out of warranty, and nobody has agreed what replaces them. Scope can include designing the target environment, deciding what moves as-is and what gets rebuilt, and setting the order of the move.
Email and files on different systems
A scenario this covers: mail sits on one system, shared drives on another, and the plan is to bring both into Microsoft 365. Scope can include auditing what exists, planning the mailbox and file moves, and agreeing on the cutover.
New software with nowhere proper to run
For example, an application is being built and lives on a machine someone set up in a hurry. Scope can include the hosting design, separate environments, and written steps for how a release reaches each one.
Method
How we would work
A starting point for the first conversation, not a fixed methodology.
- 01
Start from an inventory
We would first establish what runs, where, on what, and who depends on it. Gaps the inventory misses get found during the cutover instead.
- 02
Write the target down first
The architecture, the hosting decision and the resource plan would go on paper for you to review before anything is built. A document can be changed cheaply. A built environment has to be rebuilt.
- 03
Move in an order you approve
We would propose a sequence, a rehearsal where one is warranted, and a way back for each step. Nothing has to move at once, and some things may be better left where they are.
- 04
Hand over something readable
We would hand over diagrams, configuration notes and access records for the environment as built. That matters most when someone else runs it afterward.
Fit
Is this the right fit?
A good fit if
- Your servers are near end of life, with no agreed replacement.
- You plan to move email and shared files into Microsoft 365.
- Your setup grew piece by piece, and nobody can describe all of it.
- You want the design on paper before anything moves.
Not the right fit
An environment that already works
If the environment is designed and working, and you want someone watching it, this is the wrong page. Monitoring, patching, provisioning, server maintenance and infrastructure support belong to Managed IT & Infrastructure Services.
Work that needs hands in the room
Racking hardware, running cable, standing in a data center or walking desk to desk is not in this scope. You would need a local supplier for the physical work, and we would say so before quoting rather than after.
An application slow because of its code
If an application is slow because of how it was written rather than where it runs, moving it changes the invoice more than the behavior. Have the code and the data layer looked at first. Custom Software Development is the more honest starting point.
Questions
Questions about cloud & infrastructure
How do we plan a cloud migration?
Start with an inventory of what runs today and who depends on it. Then decide what moves as-is, what gets rebuilt, and what stays where it is. We would put the target design on paper for you to review before anything is built, then propose an order of moves for you to approve.
Which cloud provider should we use?
We would not assume one. The hosting and platform choice would be made during design, once the inventory shows what you run and what each system depends on. The recommendation would be written down for you to review before anything is built. Whichever provider you choose, the accounts would be yours.
Do we keep our own cloud accounts?
Yes. Everything Traittek builds is yours: the code, the repository, the domain and the accounts it runs on. The handover would include diagrams, configuration notes and access records, so you could run the environment yourself or hand it to someone else.
What does cloud infrastructure and migration work involve?
We would run it in four parts, in order: an inventory, a written design, the move itself, and a handover with diagrams and access records. What usually stalls a migration sits at the edges, such as a shared drive nobody owns or an application with a server name written into it. The inventory is there to find those before the move does.
Should we migrate everything at once?
Not necessarily. Nothing has to move at once. We would propose a sequence for you to approve, with a way back for each step. Some systems may be better left where they are, and some may be worth rebuilding rather than moving as-is.
Do you test that backups actually restore?
Scope can include it. Backup design and configuration would come first, then restore testing against scenarios agreed with you, and recovery plans for defined failure cases. A backup job that reports success has not shown what it would restore, in what order, or who can do it.
Start with what runs today
Tell us what you run, where it runs and what needs to change, and we would start from an inventory.