A Sharjah spare-parts distributor has a small office, a warehouse and one person who knows how the stock application works. The company wants to move its systems to the cloud before an old server needs replacing. Its shared catalogue looks easy to move. Its stock database holds more business value, but it also feeds the counter, the warehouse scanners and the nightly accounts export. Moving that database first could put several teams at risk before the company has tested its ability to restore a service.
A useful first move gives the business a visible improvement and teaches it how to run the next migration. Choose a complete workflow with known dependencies, a clear owner and a fallback that fits the trading day. Use the move to verify access, backups, support and costs. Then decide whether the company can take on something more critical.
Find the work behind each server
Start with the activities people need to finish. At the distributor, someone receives a supplier shipment, updates stock, prepares a quote and invoices a customer. Walk through the sequence with the people who do the work. For each step, record which systems and files they need, which service account or employee has access and what happens when the step fails. Ask about month-end tasks and jobs that run without a person present.
A single inventory application may depend on a database, a label printer, a shared folder and an external accounting connector. Some dependencies become apparent only during a closing routine or an unusual return. Ask finance and warehouse staff to demonstrate those cases. Observe which machines connect to which endpoints and confirm what the supplier still supports. A list of applications gives the project a starting point. A workflow map shows what has to move together or keep communicating during the transition.
Microsoft's Cloud Adoption Framework describes grouping workloads by dependencies and planning migration in waves that can be adjusted as new information appears. For a small business, this can be a short record for each workflow. Include its owner, inputs, outputs, dependencies, expected outage window and how to check it after the move. Microsoft Cloud Adoption Framework migration wave planning
Choose a first move that is useful and reversible
Give each candidate a business reason to move. A published parts catalogue might make it easier for staff at both sites to use the same version. A backup copy might give the owner a chance to test restoring data without moving the production application. A reporting job could move safely if its data feed is documented and it can still be run from the old location. Pick the candidate that resolves a real problem and gives the team a useful rehearsal for the next wave.
The UAE's National Agenda for Entrepreneurship and SMEs includes digital transformation among its themes. At company level, translate that broad theme into an outcome someone can verify, such as whether staff at both sites can retrieve the current approved catalogue or recover a file on the same shift. UAE National Agenda for Entrepreneurship and SMEs
| Candidate at the distributor | Likely place in sequence | What to prove |
|---|---|---|
| Approved product catalogue | Early bounded move | Correct version, role access and recovery |
| Backup copy of selected files | Early recovery exercise | Restore using ordinary staff procedures |
| Nightly inventory report | After testing its data feed | Scheduled run and reconciliation |
| Stock, scanners and accounts export | Coordinated later wave | Complete transactions and safe rollback |
| Obsolete file share | Review for retention or retirement | Owner confirms dependencies and required records |
The order is illustrative. A catalogue becomes a poor first move if it contains confidential negotiated prices or feeds a live quoting system that nobody has mapped. A core workload may move earlier if old infrastructure is failing and a viable alternative has been rehearsed. Record why each candidate is moving, what the team is leaving in place and when that choice should be revisited.
For each candidate, compare keeping the current setup, moving it as it is and replacing it with a hosted application. Moving an application can preserve familiar screens but leave the company responsible for patches and backups. Replacing it can remove some maintenance while creating work to convert records and train staff. Use the same business test for both options. A replacement catalogue, for example, must still let staff find the approved revision and show which version was in use for a historical order.
Prepare the few controls every wave needs
Set up named access and a way to recover it before copying live material. Decide who administers the service, who approves permissions and who can help when an employee leaves or loses a device. Test with ordinary staff accounts. Use an approved dataset for the first rehearsal, then verify the actual storage and backup configuration against the business's data constraints before the real move.
Test the network from the locations and devices that matter. A warehouse worker with a handheld device may see a different result from the consultant in the head office. Open the catalogue and print a sample label where the work happens. Check what staff can do if the usual connection drops. If one branch uses a backup mobile connection, try the workflow on it and record which functions remain usable.
A du reel shows a network demonstration in the UAE. The distributor's decision depends on its own site tests, including whether the staff devices and network can reach the service during ordinary shifts.
Assign an owner for support and for the invoice. Confirm where the company opens a ticket and how it reaches someone who can resolve account or network problems. Check that finance can see the subscription, storage and support costs. Retain enough of the old setup to run the agreed fallback and include those overlapping costs in the migration budget. Review the first provider invoice before assuming it represents a normal month.
Rehearse the move and the way back
Write down the order of the cutover. Specify who will take a backup, stop edits if required, copy the final changes, redirect users and run the first checks. Decide who can extend the window and who can call for rollback. Keep the procedure available even if the system being moved is unavailable. For a file migration, write down which copy is authoritative at each step so staff do not update both versions.
AWS Prescriptive Guidance distinguishes rollback before data changes from rollback after a new system has received transactions. Once staff have created records in the new location, switching back can leave the old data incomplete. Rehearse how to identify and recover those changes or define a temporary read-only period that keeps the fallback feasible. AWS Prescriptive Guidance on migration cutover
Suppose the distributor has a hypothetical two-hour window before order processing resumes. Its rehearsal uses 35 minutes to copy the last changes, 25 minutes to validate permissions and records, and 20 minutes to redirect users and test the workflow. That leaves 40 minutes. If the tested rollback takes 30 minutes, the team has only ten minutes of margin beyond the rollback allowance. The time to decide matters as much as the time to run the steps. Set a decision point early enough to finish reversing the move before trading restarts.
Rehearse a failed move with a small approved sample. Test a missing permission, an interrupted copy and a case created after cutover. Confirm who can resolve each situation. Ask the business owner to compare record counts and selected values rather than relying on a successful copy message. For a scheduled export, have the receiving team open and reconcile the file. The migration is only useful if the next person can complete their work.
Tell staff how the cutover will look from their side. Give them the expected downtime, where to record urgent work and how to confirm that the new service is ready. Provide a contact they can reach from a handheld device or a branch that has lost access. After the window, collect the temporary records and reconcile them against the live system before reopening normal edits. A short log of orders taken during the pause can be the difference between a clean restart and a morning spent tracing duplicate requests.
Confirm the first wave before opening the next
Set acceptance criteria a staff member can demonstrate. For the catalogue, a sales employee might find the current version, a warehouse employee might print the expected page and an administrator might restore an earlier copy into a test location. Check that someone who should have no access cannot open the files. Check the behavior from both sites and make sure the owner can change permissions without help from the migration team.
Watch the service through a full operating cycle that includes the work it supports. A reporting migration may need a scheduled run and a period-end check. Record incidents, time spent supporting the system and any use of the fallback. Ask staff what they are still doing manually. A hidden spreadsheet or an employee copying records back into the old system can indicate that the process has yet to settle.
Remove old copies or cancel services only after the business owner has confirmed recovery, retention and the end of any dependencies. An old server may still run a scheduled task even if nobody signs in. Assign a date and an owner to each retirement check. If the company needs a historical record, preserve it in a form someone can open and verify without relying indefinitely on the old application.
Use the result to choose the next wave
Compare what happened with the reason for moving. Did staff at both sites get the current catalogue? Could the administrator restore it and resolve a permission problem? What did the first month cost? Record the time, operating risks and support effort that surprised the team. Apply those lessons to the estimate for the next group rather than assuming the first result will repeat.
Before moving the stock application, the distributor should confirm the scanner, label and accounts dependencies. It can then test a complete order and reconcile a sample of opening balances, transactions and exports. If the temporary connection between old and new systems cannot handle the required traffic, bring the dependent components into the same wave or change the plan. Rehearse how the warehouse will record urgent activity while the move is underway and how those records will be entered after the service returns.
A useful migration plan remains short enough for the people doing the work to use. For each wave, name the business outcome, components, decision owner, acceptance tests and fallback. The first move earns its place when it solves a known problem and gives the team verified evidence about how to carry out the next one.


Comments (0)
No comments yet. Be the first!