Included
Standard launch services
- Standard onboarding
- Initial school configuration
- Initial data migration
- Staff training
- Ongoing product support
School ERP implementation and onboarding
A clear school ERP implementation path—from first conversation to first school day.
Schylva turns your school’s priorities into a written rollout plan covering initial migration, configuration, role-based validation, staff training, go-live and ongoing support.
No student records or confidential school data are required. We respond to demo and quote enquiries within two working days, excluding weekends and public holidays.
- Written plan
Scope, owners and acceptance checks are confirmed before activation.
- Validated launch
Representative records and priority role workflows are reviewed.
- School approval
Your school confirms readiness before moving into live use.
The rollout playbook
Six steps.
Shared decisions.
Read the school’s part, Schylva’s part and the checkpoint together. These are implementation responsibilities—not live project status or automatically completed tasks.
Understand the starting point
Understand the school before configuring the platform.
Review the academic year, board context, school structure, priority workflows and the people responsible for decisions.
Review the connected platform- School prepares
- Confirm the academic year, board context, classes, sections, priorities and decision owners.
- Schylva handles
- Turn the school’s starting point into the questions that define a useful rollout scope.
- Checkpoint before moving forward
- School context and decision ownership are understood.
Make the plan explicit
Agree the scope, owners and acceptance checks in writing.
Define the first rollout around the school’s priorities, owners, migration needs, validation checks and go-live decisions.
See what the written plan confirms- School prepares
- Confirm launch priorities, source-information owners, relevant roles, dependencies and approval responsibilities.
- Schylva handles
- Prepare the written implementation detail covering owners, migration, configuration, validation, training and timing.
- Checkpoint before moving forward
- The school and Schylva agree what will be prepared and validated.
Prepare reliable inputs
Prepare the school structure and agreed source information.
Bring the school foundation, owners and launch priorities into a reviewable context before configuration and migration proceed.
Review the school information foundation- School prepares
- Provide the agreed source information through the approved route and make the relevant owners available.
- Schylva handles
- Review readiness for the agreed people, classes, accounts, settings and priority workflows.
- Checkpoint before moving forward
- The agreed source information and school decisions are ready for the next step.
Build the approved environment
Configure the school and complete the included initial migration.
Apply the agreed school structure, role-account foundation and initial migration scope, then prepare representative records for school review.
Review role and account preparation- School prepares
- Answer configuration questions and review representative records and relationships.
- Schylva handles
- Translate the agreed structure into supported configuration and complete the included initial migration within scope.
- Checkpoint before moving forward
- Representative configuration and migrated records are ready for school validation.
Test the real roles
Validate representative workflows and prepare the relevant staff.
Review the administrator, teacher, parent and student paths included in the agreed launch scope, then record open actions.
Review the four role experiences- School prepares
- Make the relevant staff available to test representative work and complete the agreed training.
- Schylva handles
- Guide role-based workflow validation and provide the included staff training.
- Checkpoint before moving forward
- Relevant workflows are tested and outstanding actions are visible.
Move into live use
Confirm readiness, begin live use and transition into support.
Go-live follows the agreed checks and the school’s readiness decision. Ongoing support begins through the enrolled-school route provided during onboarding.
Review support after go-live- School prepares
- Approve readiness for live use and continue to supply information or action when an issue depends on the school.
- Schylva handles
- Record the agreed transition and provide the enrolled-school support route during onboarding.
- Checkpoint before moving forward
- The school confirms readiness and the ongoing support path is understood.
Know what you are agreeing to
Included services.
A school-specific plan.
Standard onboarding and launch services are included. The operational detail, owners and acceptance checks belong in the school’s written implementation scope.
Confirmed in writing for the school
School-specific implementation detail
- Agreed launch scope and owners
- Source records and migration details
- Configuration priorities
- Validation and acceptance checks
- Training arrangement
- School-specific timing and go-live plan
- Dedicated enrolled-school support route
Payment processing
Payment-gateway transaction charges remain separately payable under the selected provider’s applicable terms.
School communication
School updates use app notifications. Login verification SMS delivery is not currently available, and WhatsApp or non-login SMS are not supported product channels.
Validate the required login-delivery path separately; a configured web code does not prove SMS delivery.
Before configuration begins
An owner for the input.
An owner for the decision.
The school owns decisions and source information. Schylva configures and guides. Both sides review the result before live use.
School decides and provides
Keep school decisions and source information owned by the school.
- Nominate a decision-maker and operational contacts
- Confirm academic structure, roles and priorities
- Provide agreed source information through the approved route
- Make relevant staff available
- Approve readiness for live use
Schylva configures and guides
Translate the agreed school context into the supported platform.
- Translate the agreed structure into supported configuration
- Prepare the account and role foundation
- Complete the included initial migration within the agreed scope
- Guide representative workflow validation
- Provide included staff training and the enrolled-school support route
Both validate and approve
Use shared checkpoints before the school moves into live use.
- Agree the implementation scope and owners
- Review representative records
- Test selected role workflows
- Record exceptions, dependencies and actions
- Confirm go-live readiness
Reliable inputs, reviewable records
Prepare the context.
Then verify the result.
Identify who can supply and verify the agreed information. Provide records only through the implementation route agreed with Schylva—not through a demo or quote form.
School context to review
- Academic year, board context, classes and sections
- People and guardian relationships
- Roles and account foundation
- Relevant fee, timetable, academic and reporting configuration
- Priority launch workflows
- A named school decision-maker, source-information owner and operational contacts
- The approved route through which implementation information will be provided
Static web evidence · sample school data
Start with the school foundation.
Sample totals and class rows—not proof of a completed import, verified guardian relationships or reconciled migration. The related records still need representative checks.
Review student informationStatic web evidence · sample school data
Check the account foundation separately.
An independent static account overview. These are not the same school records as the people example, adoption metrics or evidence of tested access and login delivery.
Review user and access managementBefore the first rollout discussion
Know your starting point.
Leave the dates to the plan.
This checklist helps prepare a conversation. Final timing depends on your school’s scope, information, owners and decisions.
A private preparation checklist
What can your school
bring to the conversation?
Review your starting context. This is not a migration audit, a duration estimate or approval to go live.
0 of 7 reviewed
Bring these items to the implementation discussion
7 items still to review. Discuss these with Schylva rather than deciding them alone.
Still to review
- A school implementation owner is identified
- The approximate student count is known
- Priority workflows are selected
- The academic structure can be reviewed
- A source-information owner is identified
- Relevant school roles can join validation and training
- A preferred launch window can be discussed
Selections are not saved or submitted. Refreshing this page clears them.
JavaScript is required for the count, result, copy and reset controls. Until loading finishes, use the visible seven-item list as a manual discussion guide instead.
Separate from the preparation checklist
Before the school
begins live use.
School approval follows the agreed validation. Ticking seven preparation items does not clear these go-live gates.
- School structure reviewed
- Representative migrated records validated
- Relevant administrator and teacher workflows tested
- Parent and student access checked where part of the launch scope
- Relevant staff training completed as agreed
- Open actions and dependencies recorded
- School confirms readiness for live use
Train around the work
The right people.
Representative tasks.
Staff training is included. Administrators, teachers and relevant accounts or academic leads join the checks connected to their work. Parent and student access is validated when it is part of the agreed launch scope. Session count, duration, participants and delivery method are confirmed in the written implementation scope.
School administrators
School structure, accounts, access and operational readiness
Administrators and relevant accounts or academic leads validate the configuration and specialist workflows connected to their work.
Review school administratorsTeachers
Representative daily teaching and academic workflows
Teachers validate priority workflows such as attendance and relevant academic work before live use.
Review teachersParents
Authorised child-specific access and published information
Parents validate the authorised access and information paths included in the agreed launch scope.
Review parentsStudents
Authorised learning, academic and school-information paths
Students validate the authorised access and information paths included in the agreed launch scope.
Review studentsStatic web evidence · sample school data
Give staff a representative task.
This empty assignment workspace is not an attendance roster or a completed publishing, hand-in or review path. Current daily-attendance and matched workflow evidence remain required.
Review daily attendance validationStatic web evidence · sample school data
Review the authorised family view.
The sample 100% refers to only two marked days. The amount due is not pricing or proof of payment availability. This is not a matched result of the Teacher example.
Review the Parent experienceKeep release states separate
Validate current web.
Plan native launch access.
Complete administrator, teacher, parent and student experiences across web, iOS and Android are coming at launch with the complete approved launch feature set. Mobile access follows the same school, account and role foundation validated during implementation.
Review the mobile-app launch plan- Responsive web
- Current role workflows available for review
- iOS and Android
- Coming at launch · not currently available to download
- Before native release
- Verify workflow parity, login delivery, device support and official store listings.
After go-live
A clear support route.
Clear expectations.
Ongoing product support is included. Its resolution target is separate from the response time for demo and quote enquiries.
Included
Ongoing product support
Ongoing product support is included after go-live.
Support hours
Monday–Friday · 10:00 AM–6:00 PM IST
Support excludes public holidays.
Resolution target
24–48 working hours
Schylva targets resolving product issues within 24–48 working hours; this is not an unconditional guarantee.
When more time may be required
Dependencies remain visible
Additional time may be required when resolution depends on a third-party service, required school information or action, or circumstances outside Schylva’s reasonable control.
Enrolled-school route
Provided during onboarding
Enrolled schools receive their dedicated email or support route during onboarding.
Sales enquiries
Response within two working days
Demo and custom-quote enquiries receive a response within two working days, excluding weekends and public holidays. This is separate from the support-resolution target.
Bring a practical brief
Plan with
the right questions.
Use these guides to prepare responsibilities, evidence and acceptance checks—not to upload school records.
Implementation questions
Practical answers.
Before you agree.
What is included in Schylva implementation?
Standard onboarding, initial school configuration, initial data migration, staff training and ongoing product support are included. The school-specific written implementation scope confirms the launch scope, owners, migration details, validation checks, training arrangement, timing and enrolled-school support route.
How long does school ERP implementation take?
There is no universal implementation duration. Timing depends on the school’s size, preparation and source-information readiness, configuration breadth, agreed rollout scope, dependency turnaround and school decisions. The school-specific written implementation scope confirms the timing and go-live plan.
Do all Schylva modules need to go live at the same time?
No. Schylva’s complete approved launch feature set is available at product launch, while each school can prioritise the modules and role workflows in its written implementation plan. The sequence and readiness checks are agreed with the school before live use.
Will Schylva migrate our existing school data?
Yes. Initial data migration is included. The records in scope, formats, method, rounds, validation steps and timing are confirmed in the school’s written implementation plan. Representative migrated records are reviewed with the school before live use.
What should our school prepare before implementation?
Prepare the academic year, board context, classes and sections, people and guardian relationships, roles and accounts, relevant configuration and priority launch workflows. Identify a school decision-maker, source-information owner and operational contacts. Provide records only through the implementation route agreed with Schylva; demo and quote forms are not intended for student records or confidential school data.
Who should own the rollout inside the school?
The school should nominate a decision-maker, a source-information owner and the operational contacts needed for the agreed workflows. Schylva configures and guides the rollout, while the school reviews its structure, provides required decisions and confirms readiness for live use.
Is staff training included?
Yes. Staff training is included. Session count, duration, participants and delivery method are confirmed in the school’s written implementation scope.
Can board-specific report cards and grading rules be configured?
Yes. Schylva supports board-specific report-card formats and configurable grading scales for CBSE, ICSE and State Board school requirements. The school’s exact academic structure and reporting rules are reviewed during implementation.
How do the iOS and Android apps fit into rollout?
Complete administrator, teacher, parent and student experiences across web, iOS and Android are coming at launch with the complete approved launch feature set. The relevant role and access paths are reviewed as part of the school-specific rollout scope.
What support is available after go-live?
Ongoing product support is included. Support operates Monday–Friday, 10:00 AM–6:00 PM IST, excluding public holidays, with a target of resolving product issues within 24–48 working hours. Additional time may be required when resolution depends on a third-party service, information or action from the school, or circumstances outside Schylva’s reasonable control. Enrolled schools receive their dedicated support route during onboarding.
Does starting implementation secure the introductory offer?
No. Completing a demo, requesting a quote or starting an implementation discussion does not qualify a school. Qualification requires completed school-account activation by 31 March 2027 at 11:59 PM IST.
Plan around the school
Your priorities.
A written path to launch.
Tell us your approximate student count, priority workflows and preferred launch window. No student records or confidential school data are required. Schylva responds within two working days, excluding weekends and public holidays, to confirm the right next conversation.