From first conversation to daily use
An implementation is organised in eight stages. What each stage covers for your institution, and how long it takes, is set out in your proposal after discovery — not before.
What happens, in order
The stages are the same for every institution. Their scope is not: a business school taking academics and elective bidding has a different project from a university taking admissions, examinations and finance.
No timelines on this page
We do not publish standard delivery times, because they depend on the modules, the state of your existing data and your academic calendar. You will get dates in a proposal.
Discovery
We establish how your offices work today: regulations, programme structures, existing systems and the people involved. The outcome is an agreed scope.
Configuration
The modules are set up to your structures — programmes, fee heads, grade scales, forms, roles and permissions.
Data migration
Records are brought across from the sources and cut-off dates agreed in discovery, then checked with the office that owns them.
Integration
Connections to payment gateways, biometric devices, messaging and other systems are set up. See the integration directory.
Testing
Each department runs its own processes on the configured system before it is relied on.
Training
Training is organised by department, on the modules that department will use.
Go-live
The system goes into use for the agreed modules, usually aligned with a term or an admission cycle.
Ongoing support
Support and maintenance continue under the terms of your agreement. Existing customers reach us through the support page.
What we need from you, and what you get from us
From the institution
- A named coordinator who can reach each department.
- Access to the existing data, in whatever form it is held.
- Decisions on regulations and exceptions when they come up.
- Time from each department for testing and training.
From A & S
- A non-disclosure agreement before any institutional data is shared.
- A scope and proposal that state which modules are included.
- Configuration, migration and integration work for that scope.
- Training by department, and support under your agreement.
A checklist for the first conversation
Work through this with your colleagues before discovery. It is for your own use: nothing you tick is stored or sent, and no registration is needed. Print it to fill in by hand.
This checklist helps you prepare. It is not an assessment, and completing it does not commit either party to a scope or a date.
About implementation
Can it be adapted to our ordinances and regulations?
Much of what varies between institutions is configuration that your own staff control: the admission form, scoring criteria, fee structures, grade scales and curves, elective rules and feedback forms. Where a regulation needs something the standard modules do not do, we assess it as customised development and say so in the proposal.
What happens to our existing data?
Migration is scoped with you during discovery: which records come across, from which sources, and from what cut-off date. Student, course and faculty data can be imported from spreadsheets. We do not commit to a migration scope before we have seen the source data. The migration checklist helps you prepare.
How are our staff trained?
Training is organised by department around the modules that department will use, as part of implementation. The scope and format are agreed in your proposal.
How do existing customers get support?
Existing customers can use the support page, write to support@assoftwaregroup.com, or call +91 70427 31360 on weekdays between 10:00 and 18:00 IST. Support terms for your institution are those in your agreement.
Set out your requirements
The requirements builder turns your answers into a summary you can print or attach to a demo request.