- Essentially just rolling forward an existing Sage 50 (previously known as Sage 50cloud) setup, perhaps with some minor adjustments
- Defining requirements and processes from scratch, then planning the implementation of Sage 200 for current and future needs
Rolling forward from Sage 50 is, deliberately, simple and quick. It is only appropriate to some, not all, upgraders from Sage 50, however. If you’re upgrading from Sage 50, please see here for more details, or contact us to discuss whether simply rolling forward or a full implementation of Sage 200 is right for you.
A “from scratch” Sage 200 implementation is a bigger, more challenging project, but one that allows more to be achieved now and foundations to be laid for future change and growth. The rest of this article only covers implementing Sage 200 from scratch.
Planning a Sage 200 implementation
Planning, of course, is about making clear what needs doing, when and by who. Our experience dictates, however, that planning starts from the earliest discussion of the objectives of the project, those that are essential and those that are “nice to have”. This shapes the project. For example determining: how formally the project should be managed; and where compromises can be made to keep project scope and budget together.
Attention should then move to availability of resources. There isn’t, and perhaps shouldn’t be, a gentle way of saying that it’s far more common for resources to be a problem on the client side than ours. It is, for example, not unusual to be implementing Sage 200 in a business where the finance team is already over-stretched with day to day tasks. We’re used to this and similar challenges, and will work with you to resolve them or to adjust the implementation plan to take account of them properly.
Migrating data to Sage 200
Data migration is about: extracting data from your current software; perhaps cleaning it up; and loading it into Sage 200 with as little manual keying as possible. There’s even an IT industry acronym for it – ETL “extract, transform, load”. We’re pretty good at this, including when the starting point is old or otherwise obscure accounts software.
The crux, though, of data migration is not the mechanical movement of data from old to new. It’s checking and formal accounting reconciliations. Our project plans always require clients to sign off data migration, but you can be certain that we’ve completed full reconciliations and fixed or reported any problems, before we present you with the data to sign off.
We offer full training as part of implementing Sage 200. How training is provided varies from: short remote sessions, designed to fit into busy schedules; through on site one to one training; to classroom / round table training.
It is, however, usually difficult to separate Sage 200 training from processes. Consequently often “training” consists of sessions with managers or team leaders discussing processes and matching these to Sage 200 features. The managers / team leaders then train their staff in the new or revised processes, including how to use Sage 200.
When to implement
There isn’t a one size fits all answer to when Sage 200 should be implemented. For very disciplined organisations, used to completing month and year end reporting within a few days, then immediately after the year end is cleanest and so may be best. For other organisations, the finance team may be stretched for weeks completing the year end. In this case the best time to implement is part way through the year, and indeed it may well be part way through the month.
Sage 200 can be implemented at any time, provided: there is a clear starting point for reconciliations; and either the old software will be retained or sufficient data can be migrated to support the year end checks and any audit.
When implementation is complete
We’ll be there to help, whether you just need support as insurance, have a continuous programme of changes planned, or expect to be anywhere in between. We offer Sage200 expertise, personal attention and, when you need it, involvement.