The IT Side of Getting a Business Running Again After a Flood

Recovery advice tends to be written from a calm office. This is the sequence as it plays out when the ground floor has been under water, half your staff are dealing with their own homes, the road is cut, and a customer is asking on Viber whether their order still exists. The order of operations matters more than the completeness of any individual step.

First: safety, then power, then anything digital

Nobody reconnects equipment in a building that has taken water until the wiring has been checked by someone competent. This sounds obvious and is routinely ignored under pressure, usually by the person who most wants to get the business back. Equipment can be replaced on an insurance claim; the person restoring it cannot. Assume the distribution board, any UPS batteries and anything with a power supply that sat in water are unsafe until proven otherwise.

Second: establish what survived, without destroying it

• Do not power on water-damaged drives to check them. That is how a recoverable disk becomes a dead one. If the data matters and there is no backup, the drive goes to a recovery specialist, sealed and not dried out with a hairdryer.
• Confirm the last good off-site backup and read its timestamp before touching anything local.
• Write down the gap between that timestamp and the moment of the incident. That gap is the work to reconstruct, and it is the number the rest of the week is organised around.
• Photograph everything damaged, in place, before it is moved, with serial numbers where visible. The insurer will want this and your memory will not survive the week.
• Note what was on paper and is now pulp: signed contracts, delivery notes, the receipt book. That loss is often larger than the digital one.

How much data can you afford to lose, in money?

Two numbers decide everything about your recovery, and both should be decided in advance rather than during. The first is how much data you can lose, measured in hours of transactions. The second is how long you can be down before the loss becomes existential rather than painful. Put rupee figures against both: a day of lost orders for a small shop might be Rs 40,000, in which case paying for hourly off-site backups is obviously worth it and a hot standby server is obviously not. Most businesses never do this arithmetic and consequently buy either nothing or too much.

The practical version for most Nepali SMEs is unglamorous: everything important lives in a hosted service outside the building, backups run automatically to a second location, and someone restores one of them every quarter to confirm it works. A backup nobody has ever restored is a hypothesis. Our note on running deployment and infrastructure on a small budget covers what that costs, and it is less than most people assume.

Third: get a minimum business running, not the full system

Find the narrowest path that lets the business take an order, tell a customer the truth about it, and get paid. That is often a laptop, a phone, a cloud account and a spreadsheet, running from wherever there is mains power and a working connection. Full restoration can take weeks and the business cannot wait for it.

• Payments: a wallet QR code printed on paper and a bank account number will keep money moving with no systems at all. Wallet accounts do not care that your office is wet.
• Orders: a shared spreadsheet with the fields you actually need, and one person owning it. Do not attempt to restore the order system first.
• Communication: one Viber or WhatsApp number that customers already know, staffed by a named person during stated hours.
• Records: whatever you do in this period, log it in a form you can import later. The reconstruction is the expensive part.

Recovery is a sequence, not a project plan. Do the next thing that lets someone get paid.

Fourth: tell customers before they ask

Publish a short factual notice stating what is affected, what still works, and when you will next update, on every surface the business is listed: your site, Facebook, Google Business Profile, and a pinned message wherever your customers actually message you. Vagueness costs more goodwill than the disruption itself. Commit to an update time and meet it, even when the update is that nothing has changed. If you take orders online, put the notice on the checkout page rather than only the homepage, because that is where the anxious customers are.

If you hold customer data and any of it may have been exposed, that is a separate and more urgent communication with its own legal shape, and it should not wait for the systems to come back.

Fifth: the paperwork nobody wants to do in week one

• Insurance: photographs, serial numbers, purchase invoices and a written loss list, filed quickly. Claims that arrive weeks later with reconstructed evidence get argued over.
• Contracts: if you owe a client a delivery date, read the force majeure and notice clauses now and send the written notice they require, in the window they require. A late notice can void the protection you were counting on.
• Staff: decide and communicate how people are paid for the closed period on day two, not week three. It is the single largest factor in whether your team is still with you in a month.
• Suppliers and landlord: a written record of what was agreed verbally during the emergency, sent the same day.

Sixth: rebuild differently, because this is the only cheap moment

The rebuild is the one point where changing where things live costs almost nothing extra, because it is all being touched anyway. Anything that was a single machine in a ground-floor room is a candidate for a hosted service. Anything that depended on one person's undocumented knowledge is a candidate for a written runbook. Anything on paper is a candidate for being scanned. If the site or system was already fragile, this is also the moment to fix it properly rather than restore the problem; we take cloud and infrastructure work as often for that reason as for growth.

Do not rebuild the same physical arrangement in the same room and call it resilience. The next flood is a scheduling question, not a hypothetical, and the flood risk mapping work now possible with open data will tell you roughly what you are dealing with at your address.

The one page to write before the next monsoon

Write this while nothing is wrong, keep it to one page, print it, and put a copy somewhere that will not be under water. It should be readable by whoever happens to be there.

• Who decides, and who decides if that person is unreachable. Two names, two phone numbers.
• Where the backups are, how to reach them, and who has the credentials. Credentials in a password manager the second person can open, not in one person's head.
• The account inventory: domain registrar, hosting, payment gateway, email, social accounts, with the recovery email for each. Registered to the company, never to a personal address.
• The customer notice, pre-written with blanks, so nobody drafts under stress.
• The minimum operating mode: exactly how you take an order and get paid with no systems.
• The insurance policy number, broker's phone number and the photograph checklist.
• A test date. Restore one backup, once a quarter, and note who did it.

Monsoon here runs roughly June to September and the serious events cluster in it, so the sensible time to write this is May. Our monsoon preparedness piece covers the physical side of the same problem. If you would rather someone else worked through the technical half of it with you, that is a short conversation and a much cheaper one than the alternative.