Sahakari Software Migration Checklist: 10 Mistakes to Avoid

Changing the system that holds every member's money is a serious project, but it does not need to be a frightening one. Most failed migrations at co-operatives share the same handful of causes, and almost all of them can be avoided with preparation. Use this checklist before, during and after the move, and learn from the ten mistakes below.

Before you start: decide who owns the project

Name one responsible person, usually the manager or accountant, and one board member who can make decisions quickly. Without owners, small questions such as which interest method to use for old loans sit unanswered for weeks. Set a target go-live date at the start of a BS month, or better, the start of a quarter, so period reports stay clean.

Clean the data first

Software will faithfully store whatever you give it, including duplicates and mistakes. Spend time on these tasks:

• Give each member a unique number and remove duplicates.
• Check names, citizenship numbers and phone numbers for typing errors.
• Confirm each member's share and savings balance against the passbook.
• List every open loan with principal outstanding, interest due, next instalment date and guarantors.
• Reconcile the sum of all member balances to your last trial balance.

If the member total and the ledger do not match, find out why before importing. Importing a known difference only buries it.

Opening balances and the cut-off date

Choose a cut-off date, ideally the last day of a BS month. Everything up to that date is the old system's history; everything after goes into the new one. Record opening balances as of that date: cash, bank, each ledger head, member savings, shares and loan principals. Print the opening trial balance, have the accountant sign it and keep it with the minute book.

The ten common mistakes

1. Importing dirty data. Duplicate members and wrong balances become permanent problems.
2. No cut-off date. Staff enter some entries in both systems and some in neither.
3. Skipping the parallel run. Differences are found by members instead of by staff.
4. Training only one person. When they are absent, the counter stops.
5. Copying every bad habit. A move is a chance to drop approvals nobody uses and add controls you lack.
6. Not testing interest. Check a few loans by hand before trusting the schedule.
7. Forgetting the passbook format. Members notice immediately if it changes without explanation.
8. Ignoring backups. The first week is exactly when a mistake or power failure can happen.
9. Unclear user roles. Everyone logs in as admin, which defeats the audit trail.
10. No communication with members. People hear rumours that the books have changed and worry about their savings.

The parallel run

For a period agreed in advance, usually a few weeks, enter every transaction in both the old books and the new software. At the end of each day, compare the cash balance and the day's collection. At the end of each week, compare member balances for a sample, then the full trial balance. Record every difference, fix its cause and only close the old books when the numbers match consistently.

Training that sticks

Train people by role, not by menu. The cashier practises deposits, withdrawals, receipts and day closing. The loan officer practises applications, schedules and recovery lists. The manager practises approvals, reports and user rights. The board member learns to read the dashboard and the overdue list. Let everyone enter real examples on a test copy before touching live data. Keep a one-page guide in Nepali next to each computer.

Plan for the awkward cases

Every co-operative has a few awkward records: a loan that was rescheduled twice, a member who holds two accounts under slightly different names, a fixed deposit renewed informally, a guarantor who has since left. Make a short list of these before go-live and decide how each will be entered. Write the decision in a note and attach it to the record. Handling the awkward cases deliberately, rather than discovering them at the counter, is what separates a calm migration from a stressful one.

Also decide what will not be migrated. Ten years of closed loan history may be better kept as scanned registers or an Excel archive, with only the totals brought across. A smaller, cleaner start is easier to verify.

Communicating with members

Tell members what is happening and why. Put a notice at the counter, say it at the next meeting and explain that passbooks will be updated and balances verified. Offer to print a statement for anyone who wants to check. Members who are involved feel safe, and those who feel safe do not rush to withdraw their savings.

After go-live: the first month

When	Task
Every day	Close the day, compare cash, take a backup
Every week	Review overdue list and any posting corrections
Month end	Reconcile bank, print trial balance, review with the board
First quarter	Review roles, reports and any custom needs

Your next step

Start with one task this week: reconcile your member balances to your trial balance. That single exercise tells you how ready you are. WebsNP supports migration for the sahakari software, including data checks and a parallel run. Message us on WhatsApp at +977 9846280400 with a sample of your data, and ask about our savings group software if you also run smaller tole-level groups.

Get a demo and quote for Co-operative Hisab Kitab Software

Tell us about your business and we will reply the same working day with a demo and a clear quote. No obligation.

Chat on WhatsApp

Or call / WhatsApp +977 9846280400

Your name Phone / WhatsApp Email (optional) Business / organisation What do you need?

Request demo

More guides on Co-operative Hisab Kitab Software