IT'S NOON on Saturday. I am on the train to Wembley, for the England v Switzerland match.
As I travel, someone is sitting in a secure bunker somewhere restoring all Glover Stanbury's practice data from two servers and configuring all the programs so that we are up and running again from 9am on Monday. Well that's the theory. I don't suppose he is sat in a bunker either, more probably sat in the garden, in the sunshine, working remotely.
So why are we moving to the cloud (AKA hosted offsite servers), what does it mean and how did we get to where we are now?
Stage 1 - selling the concept
With five other partners in the practice and another director in an associated company, making decisions can be a lengthy process, sometimes taking hours of discussion. The sole practitioner has something of an advantage here.
We had flagged up for some time that one office server had reached the end of its useful life and would need replacing within a few months. It was full and we were forever deleting data to make space to keep it functioning. Another Citrix server was losing connection regularly, sometimes six or eight times a day, causing issues and discontent.
As is probably common in the majority of firms, staff were working on different versions of Microsoft Office, which is not ideal.
I was fully aware of the concept of the cloud and had 'floated' the idea a while back at a partner's meeting, that we would look at it when the time came to perform the next major upgrade. Having seen a presentation at a recent conference and discussing it in detail with another partner on the three-hour drive home, we put together a summary of the issues and calculated the time we lost through dealing with IT matters throughout the year.
With no dedicated IT support internally, we bought this IT support as and when required. Other matters included: updating software that all staff needed to use on their work PCs throughout the year; configuring and installing software when new staff arrived or when a PC was replaced; backup solutions; and numerous other considerations.
For those of us involved extensively in sorting these issues, there were huge advantages and cost savings for the firm. We would not have to regularly replace servers or buy high-specification PCs because all systems and file access would in future be handled via the internet, with all software available on a hosted, remote desktop as opposed to individual employees' desktop PCs in the office.
We also had the issue, not applicable to all firms, of having two offices about 10 miles apart. While some programs were shared via Citrix (server database technology), most of the major software, accounts production, tax, corporation tax and so on had separate databases in each office. Combining these into one database for each product would also have many benefits.
As it turned out, this was one of those decisions at a partner's meeting that did not take as long as I envisaged: we agreed that this would be the way we would move.
Stage 2 - moving the associated company
It was decided that we would move our associated company across first. These were the ones suffering the most with the lost connections and there are only three employees and three software products to migrate. We then said that a decision would be made to move the practice data without recourse to another partners' meeting, as long as there were no hiccups or problems with the company that had made the transition.
The company migration to hosting took place within four weeks of deciding. A portable USB drive was delivered to us, we gave the hosting company remote access to the servers to perform the data backup and a courier collected the disk at the end of the day. It was up and running very quickly.
The hosting staff had liaised with the software houses, with one softco having said that its software would not run in the hosted environment: the hosting staff soon disproved this and had the programs running.
Problems included a printer issue of our own making: it had not been set up as a shared printer on the network. All had gone quiet for some three weeks about computer issues, so we assumed it was working because we would have heard if it was not.
It is strange how everyone moans when something does not work yet forget sometimes how many hours go by with constant use and no problems. When we eventually asked about the shared printer issue, the feedback was that everything was fine.
As a result of all the changes, one particular member of staff was now able to work from home or clients' premises from a laptop (using a wireless wi-fi hotspot), or even in the office. A happy bunny!
Stage 3- preparing the practice for the transition
Following a meeting with the hosting company on a Friday to iron out and resolve queries, we decided to make the transition the following week, which gave us less than four days to prepare. We had thoughts of moving items piecemeal, starting with the two pieces of software running across Citrix to take that server out of the loop then moving onto other software. We were, however, persuaded that a big bang was the better way to do it.
Panic is an apt description of what some of the partners felt on announcing the migration one week later.
Why were we not assessing the other company experience after one and then three months? Why the panic to move now and not wait for four months?
There is never a good time to migrate but I know that if we had waited until September or October then the concern would be that everyone was busy with the January filing deadline not too far away. The payroll staff had a moan too: what happens if it is not working on Monday? The answer was that things would still work on the old server if necessary.
Having cleared over this hurdle, the next step was to look at the data to be transferred. One office was used to disk-space constraints while the server in the other office had huge capacity. Transferring to a hosted solution featuring an agreed disk storage limit – with extra memory use being chargeable when the base limit is exceeded – does focus the mind.
One of the first memory hogs we looked at was Outlook PST files, perhaps better known as email archives. Some of these were very small where users' emails were deleted regularly or rarely used. However, there were some were enormous.
The biggest was 12.6 Gigabytes (GB) and the second largest was 6.6GB. Some people are hoarders, failing to throw anything away or delete data just in case. The largest file had emails going back at least 12 years; if you ever wanted to know when we had cakes in the office for birthdays, running a search for 'cakes' would reveal each over the last decade.
One person said that they had cleared out their PST file but it was still nearly 2GB. Handily, they then went on holiday! We had a look and cleared out two 4 Megabyte (MB) files of a picture of a caravan that had come in and been forwarded elsewhere, with a 46mb Sage backup emailed in some four years ago that had managed to make it to an inbox despite its size. Various 'message undeliverable' files were cleared too.
Compacting the PST files had never been done before. After a bit of a clear out, archiving and compacting the 12.6GB file shrunk it to 4.5GB, with the 6.6GB file shrunk to 875k. Other significant reductions were also seen.
The moral – and time will tell – is to think at the time of reading an email 'will I ever need to look at this again'? If not, delete it there and then and empty the deleted items folder on exiting Outlook (and be careful with large files as well).
If the system ain't broke don't fix it goes the old adage, and internally things have worked fine. However this migration and rationalisation provided an opportunity to look at things that would not normally be considered on a day-to-day basis.
A review of other files in both the user's own and shared folders revealed hundreds of files no longer required or being duplicated. The hoarder alluded to when discussing Outlook was also the prime culprit with computer files.
Although only small files, we cleared at least ten Excel timesheet templates (we haven't used Excel time sheets for three years), as well as cash flows from software we no longer have. Many hundreds of others besides were also pruned.
In claiming insufficient time to look at all the files just in case, we resorted to a USB portable drive to which 20GB of 'personal' files were transferred, and then copied to the C: drive as well just in case. These were then deleted from the files to be transferred to the hosted solution.
Stage 4 - Transfer of files
Thursday afternoon and the 500GB USB drives had already been supplied; one of them was attached to the server and a backup. The emails were then redirected to the new mail server.
On Friday, someone arrived to wander around the PCs to make sure that: everything was working on the user's PCs; Outlook PST and archive files were on the network drive; internet bookmarks had been transferred; and iPhone mail syncing to the Microsoft Exchange server was working (we used Mailgate in the past to distribute emails).
Running a new backup to pick up any changes since the previous night and then backing up the SQL server files was all that was left; the office was therefore out of action for about three hours, though to be fair we could have worked on local copies of the accounts software and imported the data into the network version the following week.
That was it. The courier then arranged to collect the drives and deliver them to the bunker...garden.
So, while I was watching a largely deflated display from England in the sunshine, I spared some thought for the person reassembling the office technology jigsaw.
Find out in the next article how the transition went and the reactions from both partners and staff.
Kevin Salter is a partner in Glover Stanbury & Co, based in north Devon, and is deputy chairman of the ICAEW IT Faculty technical committee
Salter can be contacted at email@example.com.
You may also like
AccountancyAgeInsight is a frequently updated resource centre for finance professionals, offering a free and easy-to-use digital library of briefings, white papers and other information resources.