Five weeks into closures across most of the region, the question every finance director is answering is not strategic. It is whether people can reach the system. Remote ERP access turned out to be the single capability that separated organisations that kept trading from organisations that spent March improvising, and the answer had almost nothing to do with how modern their enterprise resource planning software was. It depended on one thing: whether the system had been built on the assumption that users would be in a building. The industry is already describing this as five years of cloud migration compressed into ninety days. That is not what happened, and the difference matters enormously for what you decide next.
What actually broke
The failures of the last month were remarkably consistent, and very few of them were application failures. Virtual private network concentrators sized for the fifteen per cent of staff who occasionally worked from home, now carrying everyone. Terminal server farms licensed for a fraction of the user base. Licence keys tied to hardware inside the office. Multi-factor authentication configured to trust the corporate network, which nobody was on. Server rooms that needed a person in them, in buildings that required a permit to enter. Then the physical dependencies that no architecture diagram records. Cheque printing on pre-printed stationery. Invoices requiring a company stamp. Delivery notes signed on paper. Statutory forms produced on a specific printer. Month-end reconciliations performed from a shared drive by three people sitting next to each other. Bank submissions that need a device somebody keeps in a desk drawer. Most organisations discovered that their system was perfectly capable of being used remotely, and that their process was not.
Three responses, and only one of them is urgent
Watching the last month, organisations have taken one of three paths. They are not equivalent, and they are being conflated in a way that will produce expensive mistakes. Remote access remediation. Expand the concurrent capacity, publish the application through a remote desktop or application broker, fix the authentication assumptions, move licence dependencies. Days to weeks, modest cost, entirely reversible. For almost everyone, this was and remains the correct first move. Infrastructure relocation. Move the existing system, as it is, to a hosting provider or a cloud platform. Weeks to a few months, moderate cost, solves capacity and physical access permanently, changes nothing about the application. A reasonable second step where the server room itself was the problem. Moving to a cloud edition of the software. This is not a migration. It is a re-implementation with a data conversion attached: different data model, reworked customisations, new integrations, retrained users, a fresh round of testing. Nine to eighteen months for a mid-sized group, and the single worst thing you can start while your organisation is in crisis and your revenue forecast is unknown. The compression claim conflates the first with the third. What has genuinely happened in ninety days is that a decade of deferred remote access work got done. The application modernisation backlog is exactly where it was in February.
| Decision | Constraint addressed | What remains |
|---|---|---|
| Remote access remediation | Concurrent access and authentication | Physical approvals and process dependencies |
| Infrastructure relocation | Capacity and access to the server room | Application design and working practices |
| Cloud edition re-implementation | Application and integration redesign | A separate business case and testing programme |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The emergency decisions that become permanent
Every organisation I have spoken to since mid-March has made changes it would not have approved in January. Administrative accounts shared so somebody could work at 11pm. Remote desktop exposed directly to the internet. Multi-factor prompts disabled because the help desk could not cope with the call volume. Personal laptops permitted onto the network. Vendor engineers given standing remote access because nobody could visit site. Approval limits raised so a single director could release payments alone. Each was defensible under the circumstances. The danger is not the decision; it is that nothing is written down, so in eighteen months nobody remembers that the exception was temporary, and the auditor finds it before you do. The discipline that costs an afternoon: a dated register of every emergency change, with the reason, the approver, and a review date ninety days out. Organisations that keep this register will unwind these safely. Organisations that do not will be living with March's architecture in 2023.
Practical Guidance for Cloud ERP Acceleration Planning
- Separate access, infrastructure and application decisions explicitly. Fix access now, consider infrastructure this year, and do not begin a cloud application migration while the revenue picture is unknown.
- Keep a dated register of emergency exceptions with review dates. Shared credentials, exposed remote access, disabled controls, vendor standing access, raised approval limits. This is the cheapest thing you will do all year.
- Find the physical dependencies in your process, not your architecture. Stamps, pre-printed stationery, specific printers, tokens, wet signatures, paper filing. Each one is a process redesign, not a technology project.
- Re-examine the month-end close as a distributed exercise. Who needs what data, who signs, in what order, and how each handoff works when nobody shares a desk. Write it down once and it works next month too.
- Check the licensing and contractual position of what you did in March. Concurrent user counts, remote access rights, virtualisation terms and hosting permissions. Some vendors have relaxed these temporarily; get the relaxation in writing with an end date.
- Model three revenue scenarios before approving any capital spend. A migration approved against a pre-crisis forecast is a decision made with numbers that no longer exist.
- Prioritise reversible spending. Capacity, subscriptions and short-term hosting can be unwound. Re-implementation cannot. Uncertainty is an argument for optionality, not for paralysis.
- Ask your vendor and partner for payment terms, not discounts. Cash timing is worth more than headline price in the current quarter, and most are willing to restructure rather than lose the renewal.
The Regional Angle
Four local conditions have shaped the last month here in ways the global commentary misses. The first is physical movement itself. Where national disinfection programmes and movement permit systems are in force, reaching an office or a data centre is not a matter of policy but of a permit issued to a named individual for a stated purpose. Organisations that had one system administrator who needed to be on site discovered that their entire continuity plan rested on that person obtaining a permit, and that vendor engineers could not necessarily cross an emirate or a border to help. Anything that requires hands on hardware needs at least two authorised people, in different locations, with documented permission. The second is workforce accommodation. A large share of warehouse, logistics, manufacturing and facilities staff live in shared accommodation, and where a building or camp has been placed under restriction the effect on an operation is immediate and total. This is not a remote access problem; it is a capacity problem that shows up in the system as unfulfilled orders and unposted goods receipts. Finance teams planning their close should assume warehouse counts and cut-off procedures will be disrupted in a way no ERP configuration can compensate for. The third is paper and the stamp. Regional commercial practice still runs on stamped invoices, signed delivery notes, original documents for customs and banks, and physical cheques. In the last month I have watched finance teams solve genuinely difficult problems by driving to an office to stamp a document. Where counterparties, banks and authorities have begun accepting scanned or electronically signed documents, get that acceptance in writing and keep it, because concessions granted verbally in a crisis are disputed afterwards. The fourth is the shifting compliance calendar. Authorities across the Gulf have been announcing deferrals and relief measures at short notice: filing extensions, fee waivers, rent and utility deferrals, customs duty measures, and changes to payroll and end-of-service arrangements in some jurisdictions. These arrive as circulars, they differ by emirate and by free zone, and they change the numbers in your system. Assign one person to track them, and make sure your ERP's tax and payroll configurations are being updated deliberately rather than by whoever read the announcement first.
The objection worth taking seriously
The strongest objection is that the whole cloud acceleration narrative is vendor opportunism. What organisations actually did in March was buy more virtual private network capacity and publish a few applications remotely; the systems themselves, including some genuinely old on-premise deployments, kept running. A finance team using a fifteen-year-old system over a remote desktop session closed February's books on time. The crisis demonstrated that the application layer was rarely the constraint, and now the same vendors who could not sell a migration in January are using a pandemic as a closing argument. The second objection is about the economics of deciding under pressure. Migrations approved in an emergency are negotiated badly. Scope is vague, contingency is thin, the business case is written against a forecast nobody believes, and the buyer has no leverage because the decision has already been announced internally. Crisis purchasing is the most expensive purchasing there is. Both are right, and they are the reason this piece argues for sequencing rather than acceleration. Fix access, because that is genuinely urgent and genuinely cheap. Consider relocating infrastructure if your constraint is a room you cannot enter. Defer the application decision until you can make it against a revenue forecast you trust, and use the intervening months to do the work that is valuable under either outcome: documenting the process dependencies, cleaning the master data, unwinding the emergency exceptions and writing down what actually failed in March. That evidence is the best input to a migration business case you will ever have, and it costs nothing to collect while it is fresh.
Common Questions
Should we move our ERP to the cloud now?
Not as a crisis response. Fix remote access immediately, evaluate infrastructure hosting if physical access is your constraint, and decide the application question when your forecast is stable.
Our system works fine remotely. Have we avoided the problem?
Probably not. Check the licensing position of what you enabled, the security exceptions you granted, and the process dependencies that are currently being solved by somebody driving to the office.
How long will this remote working period last?
Nobody knows, which is the planning assumption. Build for at least one more quarter of restricted operation and make every commitment reversible.
What should we expect over the next twelve months?
Expect a second wave of work to harden what was opened in a hurry, most of it security. Expect budget scrutiny to arrive by the third quarter as cash positions become clear, which will favour subscription over capital spending. Expect vendors to compete on payment terms and deferred commitments rather than list price. And expect the organisations that documented what broke in March to be the ones making good architecture decisions by the end of the year.
Cloud ERP Acceleration Planning — we separate the access fixes you need this month from the migration decision that should wait, and make sure March's emergency changes do not become next year's architecture.