Custom Software in Kenya: 12 Ultimate Steps for Success

Spreadsheets are flexible, familiar and quick to start. A small team can create a customer list, stock tracker, payment register or job schedule in a few hours. The problem appears later, when the file becomes a critical business system without the controls, workflows and reporting that critical operations require.
Moving from spreadsheets to custom software is not simply a matter of importing rows into a database. The organization must decide which processes to keep, which data to clean, which rules the new system should enforce and how users will move to the new workflow without interrupting daily operations.

This guide explains how to move from spreadsheets to custom software in Kenya in a controlled, practical way.

Signs your business has outgrown spreadsheets

A spreadsheet is still appropriate for many small, temporary or analytical tasks. The case for custom software becomes stronger when the operational risk and coordination burden continue to grow.

Common signs include:

• Several people edit different copies of the same file
• Staff cannot tell which version is current
• Formulas are frequently changed or broken
• Access is all-or-nothing rather than role-based
• Records are duplicated across departments
• Approvals happen outside the spreadsheet
• A single person understands how the file works
• Reporting requires manual copying every week or month
• Customer or payment follow-up depends on memory
• Files contain sensitive data without suitable access controls
• The business needs a customer, supplier or partner login
• Transactions must connect to M-Pesa or another system

The decision should be based on business impact. If spreadsheet limitations cause missed revenue, delayed service, reporting uncertainty or unacceptable risk, a structured system may provide a better long-term foundation.

Step 1: Inventory every spreadsheet and side process

Begin by identifying the full operational environment. The main spreadsheet rarely tells the whole story. Staff may also use personal copies, paper forms, shared folders, email templates and WhatsApp messages to complete the workflow.

For every file, record:

• File owner
• Business purpose
• People who view or edit it
• Important columns and formulas
• Where its data comes from
• Reports produced from it
• Related files or systems
• How often it is updated
• Known errors or limitations
• Whether it contains personal or sensitive data

This inventory prevents the new system from overlooking work that happens outside the official process.

Step 2: Map the process, not the spreadsheet layout

Do not ask a developer to copy every worksheet and column into software. Spreadsheets often mix data entry, calculations, notes and reports in one screen because that is convenient for a file. A proper system can separate those responsibilities.

Map what actually happens:

1. What event creates a new record?
2. Who enters the information?
3. Which data is mandatory?
4. Who reviews or approves it?
5. What calculations or status changes occur?
6. Which exceptions need special handling?
7. What document, notification or report is produced?
8. When is the record considered complete?

The new software should reflect this workflow and remove unnecessary duplication.

Step 3: Decide what belongs in the first release

Replacing everything at once increases risk. Choose a first phase with clear value and manageable dependencies.

A useful first release might include:

• One master customer or supplier record
• A core transaction workflow
• Role-based staff access
• Search and filtering
• Essential management reports
• Controlled import and export
• Audit history for important actions
• Notifications for pending work

Features such as a customer portal, mobile app, advanced analytics or multiple integrations can follow after the core process is stable.

Step 4: Clean the data before migration

Migration is the wrong time to preserve every historical inconsistency. Data cleaning should be led by the business because only the business can decide which record is correct.

Typical cleaning tasks include:

• Removing exact and near duplicates
• Standardizing customer and supplier names
• Separating combined fields such as full name and phone number
• Converting dates to one agreed format
• Standardizing branch, product and service codes
• Confirming required identifiers
• Filling critical missing values where evidence exists
• Marking inactive or archived records
• Removing obsolete test data
• Reviewing negative, impossible or outlier values

Keep an untouched backup of the original source files. Perform cleaning on controlled working copies and document the rules used.

Step 5: Define a data-mapping document

A data map shows where each source field will go in the new system and how it will be transformed.

For example:

The map should also identify fields that will not be migrated and explain why. This avoids silent assumptions during import.

Step 6: Establish one source of truth

The new system must become the authoritative source for selected records. If teams continue updating spreadsheets after launch, the organization will recreate the same version problem in a different form.

Decide:

• Which records are mastered in the new system
• When spreadsheet editing will stop
• Whether exports are for analysis only
• Who can correct data after migration
• How external systems receive updates
• How archived historical files will be accessed

Some teams use a temporary parallel period, but it should have a specific end date and reconciliation process.

Step 7: Build permissions and controls around real roles

Spreadsheets often provide broad access to everyone with the file link. Custom software allows more precise controls.

Define who may:

• View each record type
• Create and edit records
• Approve or reverse transactions
• Export information
• Manage users and permissions
• Correct migrated data
• Delete or archive records
• View audit history

Sensitive actions may require an approval step or additional authentication. Permissions should be tested with representative user accounts before launch.

Step 8: Run a trial migration

Never make the first full data import on launch day. Use a representative sample to test mapping, validation, duplicates, dates, balances and links between records.

After the sample succeeds, run a complete trial migration into a non-production environment. Business owners should compare totals and selected records with the source data.

Useful reconciliation checks include:

• Total number of customers, suppliers or employees
• Transaction counts by month
• Opening and closing balances
• Totals by branch or category
• Number of rejected rows
• Duplicate identifiers
• Missing required relationships
• Sample documents linked to the correct records

Every rejected record should have a reason and an agreed resolution.

Step 9: Test the workflow with real scenarios

Technical testing confirms that the software functions. User acceptance testing confirms that the business can operate with it.

Create scenarios from normal work and difficult exceptions. Ask users to create records, make corrections, process approvals, search history, generate reports and recover from mistakes.

Document:

• Scenario tested
• Expected result
• Actual result
• Issue owner
• Resolution
• Retest outcome
• Final approval

User testing should include different roles and branches where applicable.

Step 10: Plan cutover carefully

Cutover is the controlled move from the old process to the new system.

A cutover plan should state:

• Date and time spreadsheet updates will stop
• Final data extraction and import steps
• People responsible for validation
• Expected downtime, if any
• How users receive accounts and instructions
• Support channel for launch issues
• Criteria for proceeding or postponing
• Recovery plan if a critical problem occurs

Choose a period that reduces operational disruption, but do not assume weekends are automatically safe if key staff will be unavailable to verify the result.

Step 11: Train users by role

Training should focus on the tasks each person performs. A short role-based session is usually more useful than a long tour of every system feature.

Provide:

• Step-by-step guidance for common tasks
• Explanation of new statuses and responsibilities
• Rules for correcting mistakes
• Clear support contacts
• Guidance on passwords and sensitive data
• Short reference documents or videos
• Extra support for managers and administrators

Listen carefully during training. Questions often reveal unclear labels, missing rules or process changes that need attention before launch.

Step 12: Measure adoption and improve

The project is not complete merely because the software is online. Review whether users are completing work inside the system and whether the expected business results are appearing.

Useful measures include:

• Active users by role or branch
• Records created through the correct workflow
• Time taken to complete key processes
• Number of manual corrections
• Pending or abandoned items
• Support requests by topic
• Report preparation time
• Continued use of old spreadsheets

Use these findings to improve training, interface design and workflow rules.

Common migration mistakes to avoid

Copying the spreadsheet exactly

This preserves limitations instead of improving the process. Design around the business workflow and decisions.

Migrating all historical data without review

Old duplicates and obsolete records increase cost and reduce trust in the new system. Agree on a useful historical period and archive strategy.

Allowing both systems to remain active indefinitely

Two sources of truth create reconciliation problems. Define a firm transition plan.

Leaving data cleaning to the developer

Developers can create validation and transformation tools, but business owners must decide which records and values are correct.

Skipping user acceptance testing

The people who perform the work must test real scenarios before launch.

Treating support as an afterthought

Early questions, corrections and improvements are normal. Assign support ownership and response expectations before cutover.

Frequently asked questions

Can all our spreadsheet data be imported?

Usually much of it can, but feasibility depends on consistency, format, relationships and data quality. Some records may need cleaning, transformation or archival instead of direct import.

Do we need to stop using spreadsheets completely?

Not necessarily. Spreadsheets remain useful for temporary analysis and controlled exports. The important decision is which system is the authoritative source for operational records.

How long does migration take?

The timeline depends on the number of files, data quality, workflow complexity, integrations and testing requirements. Data review often takes longer than the actual import operation.

Can the new system connect to M-Pesa?

Yes, where the required account and API capabilities are available. The project should define how payments are initiated, verified, matched, reversed and reconciled.

Move from fragile files to a controlled business system

The best migration projects do more than replace a spreadsheet screen. They create clearer ownership, consistent data, role-based access and reports that management can trust.

Zama Web Experts helps Kenyan businesses map spreadsheet-based operations, clean and migrate data, build secure workflows and support users after launch. If your files have become a critical but fragile part of the business, contact Zama to plan a phased move to custom software.