If your school manages student records, grades, attendance, behavior, or parent progress in spreadsheets, the safest way to move to a school management system is not to import every file at once.

The right approach is to first identify which spreadsheets your school actually depends on, clean and standardize the data, decide which platform will become the source of truth, define staff access, test a small import, pilot real teacher workflows, verify the results, and only then retire the old spreadsheets.

For most small K–12 schools, replacing spreadsheets should follow this order:

1. Inventory your existing spreadsheets.
2. Decide which workflows should move.
3. Create one clean student master list.
4. Remove duplicates and inconsistent data.
5. Define classes, subjects, teachers, and school terms.
6. Decide what historical data actually needs to be migrated.
7. Set roles and permissions.
8. Map spreadsheet fields to the new system.
9. Test a small import.
10. Pilot the system with real teachers.
11. Verify the new records.
12. Set a clear cutover date.
13. Archive the old spreadsheets.
14. Stop duplicate daily workflows.
15. Measure adoption after launch.

The most important principle is simple:

Do not turn your new school management platform into one more place where school data lives. Make it the authoritative place for the workflows you choose to migrate.

For a small school primarily trying to centralize grades, attendance, behavior, student records, parent reporting, and leadership visibility, a focused school management system may be enough. Schools that also need complex enrollment, billing, state reporting, master scheduling, or other district-scale functions may require a broader Student Information System.

This guide explains how to tell the difference and how to migrate without creating more administrative work than you started with.

Spreadsheet-to-School-System Migration at a Glance

A spreadsheet migration is primarily a data and workflow project, not a file-conversion project.

A school can technically import a CSV file in minutes.

That does not mean the migration is complete.

The migration is complete when teachers know where to enter information, administrators know where to find it, access is controlled appropriately, and nobody has to ask:

Which spreadsheet is the current one?

Why Schools Eventually Outgrow Spreadsheets

Spreadsheets are not inherently bad school management tools.

For a new microschool with 15 students, one shared roster may be entirely sufficient. A teacher managing a single class can often maintain a perfectly functional gradebook in Excel or Google Sheets. A small academy may track a limited workflow manually for years without serious problems.

The problem begins when the spreadsheet stops being a document and becomes infrastructure.

That usually happens gradually.

A school creates a master student spreadsheet.

Then teachers create individual gradebooks.

Attendance gets its own file.

Behavior incidents go into a shared document.

Parent email addresses are maintained separately.

One administrator creates a reporting spreadsheet that combines several of those sources.

Someone downloads a local copy.

Another staff member creates a new version because they are afraid of breaking the original.

A teacher leaves.

A student changes class.

A parent changes an email address.

Eventually, the school no longer has one dataset.

It has several partially overlapping versions of the same school.

That is when spreadsheets become difficult to manage.

Problem 1: There Is No Reliable Source of Truth

Consider a simple question:

What class is this student currently in, and what is the correct parent email address?

The office roster may contain one answer.

The teacher's gradebook may contain another.

The parent contact spreadsheet may contain an address from the previous school year.

A mailing list may contain yet another version.

Each file may have been correct when it was created.

The problem is keeping all of them correct together.

A structured student records management system changes that model by keeping the student's current information attached to one continuing record rather than recreating that student inside each teacher's file.

Problem 2: School-Wide Reporting Becomes Manual

A principal should be able to answer questions such as:

• Which students have declining attendance?
• Which classes have not recorded grades recently?
• Which students are struggling across multiple subjects?
• Are behavior incidents increasing?
• Which families may need a progress update?
• Are there patterns that appear across several classes?

When information lives in separate teacher spreadsheets, these questions usually require someone to:

1. request files;
2. wait for responses;
3. check that the files are current;
4. combine the data;
5. resolve inconsistencies;
6. build a report;
7. interpret it.

The school is effectively rebuilding its database every time leadership wants an answer.

A centralized school analytics dashboard approaches the problem differently: the reporting layer uses the same current grade, attendance, and behavior information staff are already recording.

Problem 3: Access Becomes Hard to Control

Spreadsheet permissions usually apply to a file or folder.

School access requirements are often more specific.

A principal may need visibility across the whole school.

A teacher may only need the classes they teach.

An administrator may need school-wide operational access.

A parent should only be able to see information relating to their own child.

Under FERPA, educational agencies and institutions must use reasonable methods to ensure that school officials access only education records in which they have a legitimate educational interest. The U.S. Department of Education explains this requirement in its FERPA guidance on access to education records.

That does not mean using a particular software product automatically makes a school FERPA-compliant. Policies, vendor relationships, configuration, staff practices, data handling, and other requirements still matter.

But role-based access for school staff can make access boundaries explicit instead of relying only on shared-folder conventions and staff memory.

Problem 4: The Workflow Depends on Individual People

Ask this question:

If the teacher or administrator who created this spreadsheet left tomorrow, what would happen to the data?

Would you know:

• where the current file is stored?
• who owns it?
• what each column means?
• how the formulas work?
• which other files depend on it?
• whether there is a newer local copy?
• whether historical records will remain accessible?

If not, the school does not really have an institutional system.

It has a personal workflow the institution depends on.

A school-wide system changes ownership from:

Sarah's grade spreadsheet

to:

Grade 8 Mathematics records owned by the school.

That distinction becomes very important when staff change during the year.

When Should a School Replace Spreadsheets?

A school does not need management software simply because it uses Excel or Google Sheets.

Spreadsheets can remain excellent tools for:

• budgeting;
• scenario modeling;
• temporary calculations;
• one-time analysis;
• planning;
• inventory;
• ad hoc projects;
• data exports;
• small datasets maintained by one responsible owner.

The case for migration becomes stronger when spreadsheets are being used as a shared database for recurring student workflows.

Common warning signs include:

• teachers maintain separate versions of student information;
• administrators regularly request spreadsheet exports;
• grades have to be copied from one file into another;
• attendance is recorded in one place and analyzed somewhere else;
• behavior records are disconnected from academic records;
• parent reports require manual consolidation;
• staff regularly ask which file is current;
• formulas break when someone inserts or deletes a column;
• teachers postpone data entry until the end of the week;
• student information leaves with a staff member's account;
• leadership cannot see current school-wide information;
• access to student information is broader than necessary;
• the same student is represented differently in multiple files;
• school-year rollover requires rebuilding several spreadsheets from scratch.

One or two of these problems may be manageable.

When several happen every week, the school has probably outgrown a spreadsheet-based operating model.

Before You Migrate: Define What “Replacing Spreadsheets” Means

One of the biggest mistakes is assuming the project should eliminate every spreadsheet in the school.

It should not.

Do not begin by asking:

Which files can our new software import?

Ask:

Which recurring school workflows should no longer depend on spreadsheets?

Your school may use spreadsheets for:

• student rosters;
• grades;
• attendance;
• behavior;
• parent contacts;
• enrollment;
• tuition;
• staff schedules;
• transportation;
• payroll;
• inventory;
• assessment results;
• fundraising;
• budgeting;
• accreditation;
• extracurricular activities.

A school management platform may be an excellent replacement for some of these and entirely inappropriate for others.

For example:

The school might also keep:

• enrollment in its existing SIS;
• tuition in accounting software;
• payroll with a payroll provider;
• budgeting in Excel.

That is not a failed migration.

It is good system design.

The goal is not to eliminate spreadsheets. The goal is to stop using them as a fragmented database for workflows that require shared, current, structured student information.

For many smaller schools, the most practical starting point is the academic operating layer: school-wide gradebook, attendance tracking, student records, behavior tracking, parent progress reporting, and school-wide visibility.

Step 1: Inventory Every Spreadsheet Your School Depends On

Do not import anything yet.

First determine what actually exists.

Create a migration inventory.

Keep it simple.

For every file, separately record:

• who updates it;
• how often it is updated;
• whether it contains student information;
• whether another file contains the same information;
• whether it is still current;
• whether it contains historical information;
• whether it is actually used;
• whether it must be migrated or can simply be archived.

This exercise often reveals more than expected.

You may discover:

• three different student master files;
• teacher spreadsheets nobody in administration knew existed;
• duplicate parent contact lists;
• old files still being updated;
• historical records mixed with current records;
• important data stored in a former employee's account;
• undocumented spreadsheet formulas used for reporting.

That is valuable information.

You want to discover it before migration.

Ask Staff Three Questions

Instead of searching every folder manually, ask every staff member:

1. Which spreadsheet would create the biggest problem if you lost it today?
2. Which spreadsheet do you update every week?
3. Which spreadsheet contains information that exists nowhere else?

Those three questions usually identify the files that matter fastest.

Step 2: Decide Which System Will Own Each Type of Data

A successful migration requires explicit ownership.

After migration, staff should know where the authoritative version of each type of information lives.

For example:

You might decide:

Student roster → school platform

Grades → school platform

Attendance → school platform

Behavior → school platform

Official enrollment → existing SIS

Tuition → accounting platform

Payroll → payroll provider

This concept is often called the system of record or single source of truth.

Without it, your new software simply becomes another copy.

You start with seven spreadsheets.

You purchase a school management system.

Six months later you have seven spreadsheets plus the new system.

Nothing has been simplified.

Write the Rule Down

For every workflow being migrated, write one simple operational rule.

For example:

Beginning September 1, attendance entered in the school management platform is the school's authoritative daily attendance record.

Or:

Beginning September 1, teachers will record grades in the school-wide gradebook rather than maintaining separate operational grade spreadsheets.

The purpose is not bureaucracy.

The purpose is eliminating ambiguity.

A short verification period is useful.

Permanent duplicate systems are not.

Step 3: Create One Clean Student Master List

Your first migration dataset should be one authoritative list of active students.

Do not begin by combining every gradebook and attendance file.

Identity comes first.

At minimum, you may need fields such as:

• student ID;
• first name;
• last name;
• current class or grade;
• active/inactive status;
• required parent or guardian information;
• other identifiers required by your destination system.

The exact fields will depend on the platform and your school's requirements.

If the destination system supports bulk imports, your cleaned spreadsheet can become the starting point. Lekktura's student records system, for example, supports bulk student import from a CSV file rather than requiring schools to enter every student manually.

Step 4: Clean the Data Before You Import It

Never use migration as a faster way to move messy data.

Clean it first.

Common spreadsheet problems include:

• duplicate students;
• trailing spaces;
• inconsistent capitalization;
• missing identifiers;
• obsolete classes;
• withdrawn students mixed with active students;
• different date formats;
• old parent email addresses;
• misspelled names;
• duplicate columns;
• inconsistent subject names;
• multiple formats for the same grade level;
• staff names entered differently in different files.

Importing these issues does not solve them.

It formalizes them.

Normalize the Data

Suppose your class column contains:

• Grade 7
• grade 7
• G7
• Seventh
• 7
• Year 7

If they all mean the same thing, choose one value before migration.

Do the same for:

• subjects;
• staff names;
• status fields;
• attendance codes;
• school years;
• terms;
• class names.

Consistency becomes increasingly important once you start aggregating information across the school.

Step 5: Resolve Duplicate Student Records

Duplicate students are more dangerous than duplicate rows because they can divide one student's history between multiple profiles.

Suppose your spreadsheets contain:

• Maria Gonzalez
• Maria Gonzales
• M. Gonzalez

If these represent one student and all three are imported independently, grades may attach to one profile while attendance attaches to another.

The destination system cannot reliably determine what the school intended.

Create a duplicate-resolution process before importing.

Useful matching fields may include:

• internal student ID;
• legal name;
• current class;
• parent contact information;
• another reliable identifier your school already uses.

For ambiguous cases, manual verification is often safer than automatic merging.

Use a Stable Student Identifier Where Possible

Names alone are poor database identifiers.

Names:

• change;
• repeat;
• are misspelled;
• may contain punctuation or spacing variations.

A stable internal student ID makes it much easier to reconcile records across years and systems.

Step 6: Standardize Your School Structure

A student record only makes sense in the context of the school's structure.

Before importing grades or attendance, define:

• school year;
• terms;
• grade levels;
• classes;
• subjects;
• teacher assignments.

For example:

2026–2027

→ Grade 7

→ Mathematics

→ Teacher

→ Students

If one spreadsheet uses "Math," another uses "Mathematics," and another uses "MATH7," determine whether they represent the same subject before migration.

The same principle applies to:

• English vs ELA;
• Science vs General Science;
• Homeroom A vs Grade 6A;
• Semester 1 vs Fall Term.

The software should reflect a deliberate structure, not preserve years of accidental spreadsheet naming conventions.

Step 7: Decide How Much Historical Data to Migrate

Schools frequently assume a migration must include every historical record they possess.

That is rarely necessary.

Ask three questions.

1. Does Staff Need This Record During Normal Daily Work?

If yes, active migration may be worthwhile.

2. Does the School Need to Retain It?

Retention requirements and school policies may mean the record must be preserved.

But retention does not automatically mean live-system migration.

3. Can It Remain in a Secure Archive?

If old information is rarely accessed, a properly managed historical archive may be more practical than converting everything into the new system.

A small school might choose to migrate:

• active students;
• current classes;
• current teacher assignments;
• current parent contacts;
• current-year grades;
• current-year attendance;
• relevant active behavior history.

It might archive:

• closed school years;
• obsolete contact lists;
• old teacher spreadsheets;
• historical exports;
• reports no longer used operationally.

Do not confuse:

We must retain this record

with:

This record must be imported into the new daily system.

Those are separate decisions.

Step 8: Define Roles and Permissions Before Importing Live Student Data

Do not wait until after migration to determine who can see what.

Define access before live student records enter the system.

A simple model might look like this:

The core principle is:

Give each person the access they need to do their job, not the broadest access that is easiest to configure.

The U.S. Department of Education states that schools must use reasonable methods to ensure that school officials obtain access only to education records in which they have legitimate educational interests.

Schools can review the Department's guidance on legitimate educational interest and access to student records and its broader K–12 student data security resources.

Software does not make a school automatically compliant with FERPA or other applicable requirements.

But technical controls matter.

When evaluating software, look for features such as:

• individual user accounts;
• role-based access;
• rapid removal of staff access;
• restricted teacher visibility;
• controlled parent visibility;
• appropriate data security safeguards.

For example, Lekktura's role-based access model for schools separates principal, administrator, teacher, and parent access. Teachers are scoped to assigned classes, while school leadership has broader school-level visibility.

Step 9: Map Spreadsheet Columns to the New System

Once your data is clean, create a field-mapping document.

Do this before importing into production.

For example:

Field mapping forces you to answer important questions early.

Suppose your spreadsheet has these columns:

• Allergies
• Pickup Note
• Uniform Size
• Scholarship
• Reading Group
• Parent Language
• Internal Teacher Note

Do not automatically search for somewhere to put each field.

Instead ask:

• Does the new system need this information?
• Is this the right system for it?
• Who should be able to see it?
• Is the information still current?
• Is there another authoritative system already storing it?

Migration success is not measured by whether every old column found a new home.

It is measured by whether the right data ends up in the right system.

Step 10: Test a Small Import First

Never make your first import the entire school.

Start with a controlled dataset.

For example:

• one class;
• 15–25 students;
• one or two teachers;
• current information only.

Then inspect the result manually.

Check:

• total student count;
• student names;
• classes;
• teacher assignments;
• parent contacts;
• duplicates;
• missing values;
• access rights.

If 20 records import incorrectly, fixing them is manageable.

If 1,000 records import incorrectly, you have created a recovery project.

Keep the Original Import File

Never overwrite your cleaned source file immediately after an import.

Preserve:

1. the original raw export;
2. the cleaned migration version;
3. the exact file imported.

That gives you a clear audit trail when something does not match.

Step 11: Test Workflows, Not Just Data

A technically correct import can still produce a failed rollout.

Why?

Because migration does not end when student names appear inside the new software.

Migration succeeds when people can do their work.

Ask teachers to perform actual tasks.

For example:

1. Open a class.
2. Find a student.
3. Take attendance.
4. Correct an attendance entry.
5. Enter grades.
6. Correct a grade.
7. Add a note if appropriate.
8. Move between classes.
9. Find a student's recent history.
10. Prepare information for a parent conversation.

Do not guide the pilot teacher through every click.

Observe what happens.

Pay Attention to Hesitation

If the teacher asks:

Where do I click?

write it down.

If they accidentally open the wrong class, write it down.

If a routine task takes several minutes, write it down.

If they say:

I would rather keep doing this in my spreadsheet and enter it later,

take that seriously.

Teacher adoption is not a cosmetic implementation metric.

It determines data quality.

A sophisticated platform teachers avoid will produce worse school data than a simpler system they update consistently.

That is why high-frequency workflows deserve particular attention during evaluation. Test how quickly a teacher can use the school gradebook and attendance system during an actual school day—not only during a polished vendor demonstration.

Step 12: Choose a Representative Pilot Group

Do not test only with your most enthusiastic technology user.

A better pilot group may include:

• one technology-confident teacher;
• one average user;
• one skeptical teacher;
• one administrator;
• several real classes.

The skeptical teacher is particularly useful.

If the workflow only succeeds with a teacher who already loves trying new software, you have not learned whether it will work school-wide.

You want friction to appear during the pilot.

That is what a pilot is for.

Step 13: Test the Administrator Workflow

Teacher adoption is critical, but the administrative workflow also needs testing.

Ask school leadership to perform tasks such as:

• find one student's record;
• review a class;
• see which classes are current;
• inspect attendance patterns;
• review school-wide academic information;
• find a behavior pattern;
• prepare for a meeting with a family;
• remove a staff member's access;
• reassign a teacher.

If the principal still has to ask teachers for spreadsheets after the system is running, the migration has not solved the leadership problem.

One of the benefits of a centralized system should be that administrators can use a school-wide analytics dashboard or equivalent reporting layer without repeatedly rebuilding the school from exported files.

Step 14: Test Parent Communication

If parent communication is part of the migration, test that workflow too.

Ask:

• How does the school create the update?
• Does a teacher need to copy information manually?
• Do parents need another account?
• Does the school manage password resets?
• Can parents see only their own child?
• Can access be removed?
• Is the information current when it reaches the parent?

Different schools will prefer different models.

Some may want a traditional portal.

Others may prefer progress reports delivered through private links.

Lekktura's parent communication software, for example, uses read-only private links for individual student progress reports rather than requiring each parent to maintain another account or install an app.

The important question is not which model sounds more sophisticated.

It is:

Which model will your families actually use consistently without creating more work for the school office?

Step 15: Test Behavior Records Separately

Behavior data deserves particular care because it may contain more context and sensitivity than a simple attendance status or test score.

If behavior observations currently exist in:

• teacher notebooks;
• private spreadsheets;
• shared documents;
• email;
• informal messages,

decide what should become part of an institutional record.

Do not migrate every historical comment automatically.

Define:

• what should be recorded;
• who may record it;
• who may see it;
• how long it should remain relevant;
• how positive and negative observations are handled.

If your school wants behavior to sit alongside academic and attendance records, a school-wide behavior tracking system can make patterns easier to see across classrooms.

Again, the value comes from structured use.

A centralized collection of inconsistent notes is not automatically better than several spreadsheets.

Step 16: Run a Short Verification Period

For critical records, consider a short parallel verification period.

The purpose is to validate:

• imported rosters;
• class assignments;
• calculations;
• attendance totals;
• grades;
• permissions.

It does not mean operating two systems indefinitely.

For example, during the first several days, an administrator might compare selected records in the new platform against the cleaned migration spreadsheet.

Once confidence is established, the old operational workflow should stop.

Parallel Systems Need an Expiration Date

A migration often fails because the temporary backup system becomes permanent.

Teachers start updating whichever system they prefer.

Then:

• one system has the latest grades;
• another has the latest attendance;
• administrators no longer know which is authoritative;
• reports stop being trustworthy.

A short verification period is useful.

A permanent duplicate workflow recreates the original problem.

Step 17: Set a Clear Cutover Date

Staff should know exactly when the new system becomes official.

For example:

Starting Monday, September 14, all new attendance and grades will be recorded in the school platform. Existing spreadsheets will remain available as historical references but should no longer be updated.

A good cutover has four qualities.

1. It Is Specific

Avoid:

We are gradually switching over.

Use:

All new attendance records move Monday.

2. It Has an Owner

One person should be responsible for:

• questions;
• data issues;
• account problems;
• escalation.

3. Everyone Knows What Stops

Staff should know exactly which old processes are ending.

4. Old Operational Files Become Read-Only

Where practical, remove normal editing access.

Do not rely on everyone remembering not to use them.

Step 18: Archive Old Spreadsheets Safely

Do not simply delete the old folder.

Create a deliberate archive.

A reasonable structure may be:

School Year

→ Grade or Department

→ Record Type

→ Final File

For each archive, document:

• what it contains;
• when it was frozen;
• who may access it;
• where current records now live;
• how retention will be handled according to school policy and applicable requirements.

Use filenames that make the status obvious.

For example:

ARCHIVED_2025-2026_GRADE_7_ATTENDANCE.xlsx

is clearer than:

Attendance_Final_V7_UseThisOne.xlsx

The objective is to prevent the archived file from quietly becoming operational again.

Step 19: Remove Duplicate Daily Processes

Once the new workflow is stable, review the school again.

Ask:

• Are teachers still keeping private grade spreadsheets?
• Is the office maintaining duplicate attendance?
• Are behavior records being entered twice?
• Are parent reports still assembled manually?
• Does the principal still request spreadsheet exports?
• Are student names being copied between systems?

Every duplicate process should have a reason.

If nobody can explain why it is still necessary, remove it.

A successful software migration should reduce administrative work.

It should not simply relocate it.

Step 20: Measure Adoption After Launch

Do not measure implementation success by the number of accounts created.

Measure whether the system became part of normal school operations.

Useful metrics include:

Data Freshness

How quickly is attendance entered?

How current are grades?

Coverage

What percentage of active classes contain current information?

Duplicate Work

Are teachers still maintaining parallel operational spreadsheets?

Administrative Retrieval

Can the principal answer routine questions without asking teachers for files?

Parent Reporting Effort

Can progress updates be prepared from current records, or does someone still manually assemble them?

Support Burden

How often do teachers need help completing routine actions?

Missing Records

Are there classes with unexplained data gaps?

A successful rollout is not:

100% of teachers logged in once.

A successful rollout is:

Current student information is created consistently as part of normal school work.

A Practical Migration Timeline for a Small School

There is no universal implementation timeline.

A 40-student microschool and a 1,500-student K–12 school should not follow the same process.

For a smaller school replacing relatively straightforward spreadsheet workflows, a rollout might look like this:

A more detailed version might look like this.

Days 1–3: Discovery

• inventory spreadsheets;
• identify file owners;
• identify duplicate data;
• decide workflows to migrate;
• identify historical information;
• define systems of record.

Days 4–7: Cleanup

• create student master list;
• resolve duplicates;
• validate current students;
• validate parent information;
• normalize classes;
• normalize subjects;
• identify old records to archive.

Week 2: Configuration

• create school structure;
• add staff;
• assign roles;
• create classes;
• assign subjects;
• prepare import files;
• run first test import.

Weeks 2–3: Pilot

• use real students;
• enter real attendance;
• enter real grades;
• test corrections;
• test administrator access;
• test reporting;
• gather teacher feedback.

Weeks 3–4: Migration and Cutover

• correct issues;
• import remaining active records;
• verify counts;
• announce cutover;
• begin official use;
• freeze old spreadsheets.

This timeline is an example, not a promise.

A school migrating years of historical data, multiple integrations, billing, state reporting, or district-level processes should expect a more complex implementation.

What Data Should You Move First?

A practical migration order is:

1. School Structure

• school year;
• terms;
• grades;
• classes;
• subjects.

2. Staff

• principals;
• administrators;
• teachers;
• role assignments.

3. Active Students

• student identity;
• current class;
• essential current information.

4. Teacher Assignments

Determine which teacher owns which subject or class.

5. Required Parent or Guardian Information

Only migrate what is appropriate for the workflow.

6. Current Operational Records

Depending on your migration plan:

• grades;
• attendance;
• behavior;
• comments.

7. Historical Information

Only after the current system is stable.

This order matters because academic records need context.

There is little value in importing thousands of grade records before the new system correctly understands:

student → class → subject → teacher → date.

What Should You Not Migrate?

Migration is an opportunity to leave unnecessary data behind.

Do not automatically move:

• obsolete student rows;
• duplicate rosters;
• abandoned calculation columns;
• unused formulas;
• old staff access lists;
• invalid email addresses;
• outdated class names;
• hidden columns nobody understands;
• temporary comments;
• formatting artifacts;
• copies of information already stored authoritatively elsewhere.

A migration is not a museum preservation project.

Its purpose is to create a cleaner operating environment for the school.

Records that need to be retained can be handled according to your school's retention requirements without necessarily being imported into the daily production system.

Spreadsheet vs School Management System: What Actually Changes?

The fundamental difference is not:

Excel vs web browser.

It is the data model.

In a Spreadsheet

The file is usually the unit of organization.

A teacher may own a file.

Students exist as rows.

Permissions generally apply to the entire file.

Grades may exist independently from attendance.

Information may have to be copied into parent reports.

Leadership may only see the data when someone exports or emails it.

In a School Management System

The student becomes the organizing record.

A student can remain the same student across:

• classes;
• subjects;
• teachers;
• grades;
• attendance;
• behavior;
• reporting periods.

Permissions can follow roles rather than files.

The school retains the record when teachers change.

Leadership can see school-wide information from the same underlying data.

That is the real reason schools migrate.

They are not replacing cells with screens.

They are replacing documents containing student information with structured institutional records.

Example: An 80-Student Private School Moving Off Spreadsheets

Consider a private K–8 school with:

• 80 students;
• 9 teachers;
• one principal;
• one part-time administrator.

The school currently uses:

• one master student spreadsheet;
• nine teacher grade spreadsheets;
• paper attendance;
• one shared behavior document;
• manual parent emails.

Every month, the principal asks teachers for updated information.

Here is what a practical migration could look like.

Step 1: Define the Scope

The school decides to centralize:

• active student records;
• grades;
• attendance;
• behavior;
• parent progress updates.

It keeps:

• accounting in accounting software;
• payroll with its provider;
• enrollment documentation in its current system.

Step 2: Create One Student Master

The administrator consolidates the active roster.

Duplicate contacts are resolved.

Withdrawn students are separated from active students.

Step 3: Standardize Classes

The school agrees on one naming system for:

• grade levels;
• subjects;
• teachers;
• school terms.

Step 4: Configure Access

Teachers receive access to assigned classes.

The principal and administrator receive school-wide operational visibility.

Step 5: Pilot One Class

One Grade 6 class is imported.

The teacher uses it for:

• attendance;
• actual assignments;
• actual grades.

Step 6: Fix Problems

The pilot reveals:

• one duplicate student;
• two outdated parent email addresses;
• one subject incorrectly assigned.

These are corrected before the full rollout.

Step 7: Import the Remaining School

The cleaned active roster is imported.

Classes and teachers are assigned.

Step 8: Cut Over

Beginning Monday, grades and attendance are entered in the shared platform.

Old operational teacher gradebooks become historical references.

Step 9: Change the Principal's Workflow

This step is frequently overlooked.

The principal stops requesting nine spreadsheet files.

Instead, school leadership reviews current information directly.

If management continues behaving as though the spreadsheets are authoritative, staff receive mixed signals about which system matters.

How to Choose a School Management System for a Spreadsheet Migration

If replacing spreadsheets is your main problem, evaluate software differently from a district buying a full enterprise SIS.

Start with the workflows you want to fix.

Can You Import Existing Students in Bulk?

If your first implementation task is manually typing hundreds of students, friction begins immediately.

Ask:

• Does the platform support CSV?
• What fields are required?
• Can imports be tested safely?
• Can students be updated later?
• How are duplicates handled?

How Fast Is Grade Entry?

Do not just ask whether the product “has a gradebook.”

Almost every school platform does.

Instead test:

• entering a full class of grades;
• correcting a score;
• adding a comment;
• changing classes;
• reviewing a student's history.

The practical question is:

Is this easier than the teacher's current spreadsheet?

If not, adoption may be difficult.

How Fast Is Attendance?

Attendance is one of the highest-frequency actions in school software.

Test it under realistic conditions.

Do not evaluate it while sitting comfortably in a 45-minute vendor presentation.

Evaluate it as if:

• 27 students just entered the room;
• another class starts shortly;
• one student is late;
• another has an excused absence;
• the teacher has other work to do.

Lekktura's school attendance software, for example, is designed around per-lesson attendance and same-day school-wide visibility.

Whatever platform you evaluate, the workflow should be tested under similarly realistic conditions.

Do Grades, Attendance, and Behavior Connect to the Same Student?

If each function operates like an isolated database, you may simply be replacing several spreadsheets with several software modules.

A stronger architecture keeps these records connected to the same underlying student identity.

Can Leadership See Current Information?

A major reason to centralize information is to remove the reporting delay.

Ask whether school leadership can see:

• current grades;
• attendance trends;
• behavior trends;
• class activity;
• student-level patterns.

without requesting new exports from teachers.

Are Permissions Role-Based?

Ask:

• Can teachers see classes they do not teach?
• Can an administrator access school-wide information?
• Can access be removed immediately when someone leaves?
• Does removing a teacher delete their historical records?
• What can parents see?

Permissions often seem unimportant during a sales demo.

They become very important after rollout.

What Happens When a Teacher Leaves?

The student's history should remain with the school.

If a teacher leaves mid-year, the school should be able to remove access and reassign responsibilities without losing:

• grades;
• attendance;
• behavior;
• class history.

What Happens When a Student Changes Class?

The student's history should remain coherent.

Changing class should not create a new identity for the same student.

Can Historical Records Be Archived?

Schools regularly need information after it stops being part of the active daily workflow.

Check whether the platform has a safe approach to archiving.

How Does Parent Access Work?

Evaluate administrative effort, not just features.

A traditional parent portal may work well for your community.

Another school may prefer parent progress reporting without separate parent accounts.

The correct question is:

Will families actually use it, and how much office administration will it require?

Do You Need a School Management Platform or a Full SIS?

This is one of the most important questions to answer before migrating.

A full Student Information System may be appropriate when your school needs:

• complex enrollment;
• registration workflows;
• master scheduling;
• tuition or billing;
• official transcripts;
• state reporting;
• district integrations;
• transportation;
• extensive compliance workflows;
• other institution-wide administrative functions.

A more focused school management platform may be sufficient when your main problems are:

• separate teacher gradebooks;
• attendance spreadsheets;
• fragmented student records;
• behavior notes;
• parent progress updates;
• teacher access;
• school-wide academic visibility.

The largest system is not automatically the best system.

The best system is the one that covers the workflows your school genuinely needs without adding unnecessary operational complexity.

For a broader comparison, see Best School Management Software in 2026: 10 Platforms Compared.

If you specifically run a smaller organization, the guide to school management software for small schools compares platforms from the perspective of smaller teams, tighter budgets, and limited IT resources.

Can You Keep Your Existing SIS and Still Replace Spreadsheets?

Yes.

Replacing spreadsheets does not necessarily mean replacing your SIS.

This is particularly important for:

• charter schools;
• private schools;
• independent schools;
• smaller K–12 organizations.

A school may already have a system required for official administrative workflows but still find that teachers rely on spreadsheets for everyday work.

A possible architecture is:

Existing SIS

Used for:

• official enrollment;
• state reporting;
• transcripts;
• scheduling.

Daily school platform

Used for:

• gradebook;
• attendance;
• behavior;
• teacher workflow;
• parent progress;
• leadership visibility.

The critical requirement is defining which system owns which information.

If the same record is actively maintained in both systems with no clear integration or operating rule, inconsistency will return.

If you are evaluating this distinction, the Lekktura vs PowerSchool comparison explains the difference between a focused daily school operations platform and a broader SIS.

The Most Common Spreadsheet Migration Mistakes

Mistake 1: Importing Everything

More data is not automatically better.

Migrate what needs to be live.

Archive what needs to be retained.

Do not move obsolete information simply because it exists.

Mistake 2: Importing Before Cleaning

Dirty data becomes harder to correct once other records start depending on it.

Clean student identity and school structure first.

Mistake 3: Maintaining Two Sources of Truth

This is one of the most damaging mistakes.

If teachers enter grades in spreadsheets while administrators expect the school platform to be current, both systems become unreliable.

Mistake 4: Giving Everyone Administrator Access

Do not solve a permission problem by giving everyone maximum access.

Assign access intentionally.

Mistake 5: Allowing Everyone to Name Things Differently

If one teacher creates:

Math

another creates:

Mathematics

and another creates:

MATH 7

school-wide reporting becomes unnecessarily fragmented.

Standardize the school structure centrally.

Mistake 6: Training Staff on Features Instead of Workflows

Do not spend the entire onboarding session showing every menu.

Train teachers on what they need tomorrow morning:

Open the class.

Take attendance.

Enter grades.

Correct a mistake.

Find a student.

Prepare for a parent conversation.

Once daily workflows are stable, advanced capabilities can follow.

Mistake 7: Choosing Software Before Defining the Problem

A platform with 200 features can still fail to solve your school's five most painful workflows.

Write down the problem first.

Evaluate software second.

Mistake 8: Migrating During a Critical Reporting Period

Avoid introducing unnecessary operational risk during:

• final grading;
• accreditation review;
• major examinations;
• state reporting deadlines;
• other critical periods.

Choose a cutover window that leaves room to identify and correct mistakes.

Mistake 9: Keeping “Backup” Spreadsheets Forever

A read-only historical archive is useful.

A live duplicate gradebook is not.

Mistake 10: Assuming the Hardest Part Is the Import

The CSV import is often the easy part.

The difficult questions are:

• Which record is correct?
• What should move?
• Who should see it?
• What becomes authoritative?
• How will teachers actually use the platform?
• When will the old workflow stop?

That is the real migration.

How Lekktura Supports Schools Moving Away From Spreadsheets

For schools whose primary problem is fragmented daily academic workflows rather than replacing an enterprise SIS, Lekktura for Schools is designed as a focused K–12 school management platform.

Instead of trying to manage every possible administrative function, it brings several everyday workflows together:

• student records;
• school-wide gradebook;
• attendance tracking;
• behavior tracking;
• parent progress reports;
• school analytics;
• role-based staff access.

For an existing school, one of the most important migration steps is getting the student roster into the system without re-entering every student manually.

Lekktura supports bulk student import from a spreadsheet through CSV. Students are organized into classes and subjects, and grades, attendance, and behavior remain connected to the student's record.

That means the starting point for a spreadsheet-based school can be relatively straightforward:

clean existing roster → import students → create school structure → assign teachers → begin using real classes.

Lekktura is not positioned as a full district SIS.

Schools that need complex enrollment compliance, billing, state reporting, master scheduling, or other large institutional workflows may still need a broader system.

That distinction matters.

A small private school should not buy software based on the number of modules in a feature matrix.

It should first determine which workflows are creating the most administrative friction.

If the answer is:

Our grades, attendance, student progress, behavior, parent updates, and school-wide reporting are spread across too many spreadsheets and people,

then a focused school management platform may be a more appropriate starting point than a large SIS implementation.

For schools still comparing options, see:

• Best School Management Software for Small Schools
• 10 Best School Management Software Platforms in 2026
• Lekktura vs PowerSchool
• School Management Software Pricing in 2026

School Spreadsheet Migration Checklist

Use this checklist before replacing a spreadsheet-based school workflow.

Discovery

• List every spreadsheet used for recurring school operations.
• Identify the owner of every important file.
• Identify files containing student information.
• Identify duplicate sources.
• Determine which files are current.
• Decide which workflows actually need to migrate.

Data Cleanup

• Create one authoritative active-student list.
• Resolve duplicate students.
• Standardize student names.
• Validate current classes.
• Validate subject names.
• Validate teacher assignments.
• Validate parent contact information.
• Separate active and historical records.
• Remove obsolete fields where appropriate.

System Design

• Define the source of truth for every migrated workflow.
• Define classes and subjects.
• Define administrator access.
• Define teacher access.
• Define parent access.
• Decide which historical data needs migration.
• Decide what can remain archived.

Import

• Create a field-mapping document.
• Preserve the original source file.
• Test a small import first.
• Verify student counts.
• Verify classes.
• Check duplicates.
• Verify teacher assignments.
• Verify permissions.
• Import remaining active students.

Pilot

• Use real classes.
• Take real attendance.
• Enter real grades.
• Test corrections.
• Test student lookup.
• Test administrator visibility.
• Test parent reporting if applicable.
• Record every point of confusion.

Cutover

• Set a specific cutover date.
• Communicate which old workflows stop.
• Stop entering new records into old spreadsheets.
• Make historical files read-only where practical.
• Archive old records.
• Document the new source of truth.

After Launch

• Check data freshness.
• Check every active class.
• Identify teachers needing support.
• Remove unnecessary duplicate workflows.
• Review permissions.
• Review parent reporting.
• Review the migration after 30 days.