SALT
Salvation Army SALT College of Africa
Feature Comparison
Legacy System vs New Platform
| Document: | Feature Comparison Analysis |
| Version: | 1.0 |
| Date: | 20th February 2026 |
| Prepared By: | Sumba Group Limited |
| Developed By | Sumba Group Limited |
| Classification: | Internal |
1. Executive Summary
The E-Learning Platform serves theological education across multiple countries including Kenya, Rwanda, Burundi, Zimbabwe, and others. This document provides a comprehensive comparison between the legacy system and the new overhauled platform, delivered in 20th February 2026.
The overhaul addressed three core objectives:
- Modernize the technology stack — replacing the legacy JSF/PrimeFaces frontend with Next.js 16 (web) and Flutter (mobile + executive dashboard), upgrading Spring Boot from 3.3.3 to 3.4.2, and introducing MinIO, Redis, Flyway, and Docker.
- Fix production bugs — 9 critical production bugs were identified and resolved, covering data loss, registration failures, search deficiencies, and approval workflow issues.
- Add new capabilities — 15+ entirely new modules were introduced (billing, suspension management, certificates with QR verification, configurable grading, intake configuration, chatbot, executive dashboard, mobile app, and more), along with significant enhancements to every existing feature.
All changes were made with full backward compatibility with the production database (salvation.sql). No tables or columns were dropped or renamed. All ID formats and conventions were preserved. The new platform supports the complete student lifecycle: registration, enrollment, study, assessment, grading, and certification.
2. Technology Stack Comparison
| Component |
Legacy System (Old) |
New Platform |
Status |
| Backend Framework |
Spring Boot 3.3.3 |
Spring Boot 3.4.2 |
Enhanced |
| Language |
Java 17 |
Java 17 |
— |
| Web Frontend |
JSF / PrimeFaces (JavaServer Faces, Apache Ant build) |
Next.js 16 (TypeScript, Tailwind CSS 4, App Router) |
New |
| Mobile App |
None |
Flutter (Riverpod 3.x, GoRouter, Dio) — 9 screens + chatbot |
New |
| Executive Dashboard |
None |
Flutter (Riverpod 3.x, fl_chart) — analytics app |
New |
| JWT Library |
jjwt 0.6.0 |
jjwt 0.12.6 (HS256, 256-bit minimum key) |
Enhanced |
| File Storage |
Filesystem only (/opt/salt_files) |
MinIO (S3-compatible) with dual-read fallback to filesystem |
New |
| Caching |
None |
Redis 7 (Alpine) — named caches with configurable TTL |
New |
| Database Migrations |
None (manual SQL scripts) |
Flyway (V1–V7, baseline-on-migrate) |
New |
| Containerization |
None |
Docker Compose (PostgreSQL 17, Redis 7, MinIO) |
New |
| Integration Testing |
None |
Testcontainers for integration testing |
New |
| Database |
PostgreSQL 17 |
PostgreSQL 17 (unchanged) |
— |
| PDF Generation |
Limited / none |
OpenPDF 2.0.3 + ZXing 3.5.3 (QR codes) |
New |
| Excel Export |
Basic |
Apache POI 5.2.3 |
Enhanced |
3. Feature Comparison
New Feature did not exist in the legacy system
Enhanced Existing feature significantly improved
Fixed Existing feature had bugs that are now resolved
3.1 Authentication & Security
| Feature |
Legacy System |
New Platform |
Status |
| Login Flow |
Basic single-step JWT authentication with username and password |
2-step authentication: credentials validation followed by OTP/access code verification sent via SMS or email |
Enhanced |
| Brute Force Protection |
None — unlimited login attempts allowed |
Configurable lockout after N failed attempts. Account locked until timeout expires. Failed attempts logged in tbl_login_logs |
New |
| JWT Security |
jjwt 0.6.0 with basic signing |
jjwt 0.12.6, HS256 with 256-bit minimum key padding, signing key from tbl_sys_settings |
Enhanced |
| Must-Change-Password |
Basic password reset |
MCP flag set on new users and admin-reset passwords. System enforces password change before dashboard access. Complexity rules enforced (8+ chars, letter + number + special) |
Enhanced |
| Session Timeout |
Fixed timeout |
Configurable idle timeout via System Settings (idle_time_out). Redirect to login with appropriate message on expiry |
Enhanced |
| Role-Based Access |
4 roles with basic route protection |
4 roles (Admin/Tutor/ETO/Student) with granular route protection across web, mobile, and API. Access level hierarchy (5/8/9/12) enforced at controller level |
Enhanced |
3.2 Student Registration & Enrollment
| Feature |
Legacy System |
New Platform |
Status |
| Registration Form |
Manual form with basic fields |
Comprehensive form with name, email, phone, territory, rank, and session dropdown (searchable, alphabetically sorted: A1 Out, Ambassadors of Grace, etc.) |
Enhanced |
| Sessions Dropdown |
No session selection |
Alphabetical searchable dropdown with real-time filtering. Sessions include: A1 Out, Ambassadors of Christ, Ambassadors of Grace, Ambassadors of Holiness, Aux-Captains/Lieutenants, and admin-configured options |
New |
| Intake Configuration |
No intake periods — enrollment open at all times |
Admin configures monthly intake periods with start/end dates. BLOCK mode prevents out-of-period registration; WARNING mode allows with notification. Visible to students during enrollment |
New |
| Mobile Registration |
Not available — web only |
Full registration via Flutter mobile app with same field validation and session selection |
New |
| Continuing Students |
Registration number defaulted to "NA" for continuing students, causing enrollment rejections |
System auto-captures existing registration number. No "NA" placeholder. Continuing students keep their admission number, avoiding rejection and re-enrollment cycles |
Fixed |
| Student Search |
Limited search — unreliable for finding specific students |
Optimized search by 3 unique identifiers: email address, registration number (all formats: 7-digit, 4-digit, phone, UUID), and phone number. Case-insensitive, BOM-cleaned, whitespace-trimmed |
Enhanced |
| Student Tallying |
No cumulative counting |
Cumulative totals of all students with breakdown: new vs continuing per territory. ETO sees own territory; Admin sees all |
New |
| Admission Status Flow |
Basic P/D/N statuses |
Complete flow: U (Uploaded) → N (Pending ETO) → EP (ETO Passed) → P (Approved) or ER/AR (Rejected). Full JSON audit trail for every status change |
Enhanced |
3.3 ETO & Admin Approval
| Feature |
Legacy System |
New Platform |
Status |
| ETO Biodata Visibility |
Limited student details during approval |
Full biodata during approval: name, email, phone, DOB, gender, marital status, rank, country, territory, admission number, registration channel. Plus previous academic performance (subjects, scores, grades) for continuing students |
Enhanced |
| Download Before Approve |
No download requirement |
ETO must download student list (Excel export) before performing approvals. Filterable by New and Continuing entry types. Includes admission number, name, email, phone, territory, registration date, status |
New |
| Application Tracking |
No visibility into approval stages |
ETO tracks each student through all registration stages (U, N, EP, P, ER, AR). Status history audit trail shows every transition with timestamps and officer names |
New |
| Three Approval Categories |
All students listed together |
ETO approval page distinguishes: (1) New students (first-time), (2) Continuing students already registered, (3) Continuing students not yet registered. Each clearly labeled and filterable |
New |
| Admin Approval Guards |
Could accidentally reject already-approved students |
System guards against rejecting students who have already been approved. Status validation at every step prevents invalid state transitions |
Fixed |
| Re-registration After Rejection |
Unclear re-registration path after ER/AR |
Students with ER (ETO Rejected) or AR (Admin Rejected) status can re-register. New enrollment record created without affecting previous records |
Enhanced |
| Previous Performance Re-upload |
Not possible after approval |
Admin can re-upload previous performance records for continuing students even after approval at both ETO and Admin levels. Missing subjects added without re-enrollment |
New |
3.4 Subject & Curriculum Management
| Feature |
Legacy System |
New Platform |
Status |
| Level Progression Gating |
Flat subject list — no enforced progression between levels |
System enforces Foundation → Certificate → Diploma progression. Student must pass all subjects in current level before accessing next. Non-Soldiers skip Foundation (Certificate → Diploma) |
Enhanced |
| Subject Visibility |
All subjects visible to all students |
Students see only current-level subjects for selection. Completed subjects shown as read-only. Next-level subjects hidden until progression criteria met |
Enhanced |
| Tutor-Subject Assignment |
Basic tutor assignment |
Admin assigns tutors per subject during student approval. Tutor-subject-student relationship created and validated. Tutor sees students under their assigned subjects |
Enhanced |
| Tutor Reallocation |
Not available — no way to reassign students to different tutors |
Admin can reallocate students to different tutors on a need basis. All progress preserved (assignments, marks, exam scores). Change logged for audit. Admin-only permission |
New |
| Subject Cost Tracking |
Subject costs existed but not systematically tracked |
Subject costs tracked per enrollment and integrated with the billing module. Costs reflected in billing calculations automatically |
Enhanced |
3.5 Assignment Management
| Feature |
Legacy System |
New Platform |
Status |
| Monthly Upload Limit |
No limit on uploads or submissions |
Admin-configurable monthly limit per subject (default: 3). Changing limit in System Settings takes effect immediately. Enforcement applies to both tutor uploads and student submissions |
New |
| Date Filter Accuracy |
Off-by-one errors in month filtering — wrong month displayed (Bug 8) |
Accurate date filtering. Filter matches actual upload timestamp with no shifted-month errors. September shows September, not August or October |
Fixed |
| Assignment Retakes |
No formal retake mechanism |
Up to 3 retake attempts for failed assignments. Previous scores preserved. Retake count incremented automatically. After 3 failures, student directed to oral assessment |
New |
| Tutor Comments as Marking Scheme |
Comments not systematically captured or downloadable |
All tutor comments on marked assignments are treated as the marking scheme. Comments visible to student, tutor, and admin. Archived and downloadable |
New |
| Material Reuse |
Materials uploaded once, no reuse capability |
Admin can reuse reading materials and assignments across multiple intake periods on a monthly basis within the year. Materials linked without re-uploading |
New |
| Marking Visibility |
No visibility into marking progress for any role |
Tutor: sees per-subject breakdown (total, marked, pending). Admin: platform-wide view filterable by tutor/subject/territory. Student: sees status per submission (N/R/T/P). Updates reflect on next page load |
New |
3.6 Exam Management
| Feature |
Legacy System |
New Platform |
Status |
| Online Exams (MCQ) |
Online MCQ exams with basic auto-grading |
Online MCQ exams with improved auto-grading, timer enforcement (auto-submit on expiry), and comprehensive result display including correct/incorrect answers |
Enhanced |
| Downloadable PDF Exams |
Not available — online exams only |
Tutor creates downloadable exam (flag: downloadable=true), uploads exam PDF, sets submission deadline. Student downloads PDF, completes offline, uploads answer PDF. Late submissions blocked after deadline |
New |
| Exam Retakes |
No retake mechanism |
Up to 3 retake attempts. New quiz record created per attempt. Previous attempts preserved. Retake count tracked. After 3 failures, online access blocked for that subject |
New |
| Oral Exams |
No oral exam workflow |
After 3 failed retakes, student takes oral exam. Tutor/Admin manually enters oral assignment score and oral exam score. Scores integrated into final grade calculation |
New |
| Quiz Auto-Population |
Manual quiz record creation |
Quiz records (tbl_student_quiz) auto-generated for all enrolled students when exam is created. All have pending status by default |
New |
| Exam Reports |
Basic exam results |
Comprehensive exam reports with pass rates, average scores, score distributions, highest/lowest performers. Filterable by subject, date range, territory. Export to Excel/PDF |
Enhanced |
3.7 Grading System
| Feature |
Legacy System |
New Platform |
Status |
| Grade Tiers |
Hardcoded grading thresholds in code |
Configurable 6-tier system stored in tbl_grading_config (seeded via Flyway V5): High Distinction (85-100), Distinction (75-84.99), Credit (65-74.99), Merit (55-64.99), Pass (50-54.99), Fail (0-49.99). Editable by Admin |
Enhanced |
| Weighted Formula |
Fixed or unclear weight calculation |
Configurable weights: Final = (Assignment Avg * assignment_weight_pct / 100) + (Exam Score * exam_weight_pct / 100). Weights must total 100%. Configured via System Settings. Changes apply to future calculations only |
Enhanced |
| Admin Score Override |
No override capability |
Admin can edit final scores with mandatory reason. Audit trail records admin name, reason, and timestamp. Grade tier recalculated automatically |
New |
| Student Grade Summary |
Basic grade display |
Comprehensive view: all subjects listed with individual scores, weighted grades, grade tiers, and overall GPA/average. Available on both web and mobile |
Enhanced |
3.8 Entirely New Modules
The following features did not exist in the legacy system and are entirely new in the overhauled platform.
| Feature |
Legacy System |
New Platform |
Status |
| Billing Module |
No billing system |
Complete billing: per-subject cost tracking, new vs continuing student rates, billing history per student, Excel export (single student or date range), line items per subject. Tables: tbl_billing, tbl_billing_items |
New |
| Suspension Management |
No suspension system |
1-year completion deadline per subject. Automatic suspension via scheduled job. Admin can search, lift, or decline suspensions with comments. ETO notified. Lifted suspension resets 1-year deadline. Full audit trail in tbl_suspension_log |
New |
| Certificates & Transcripts |
No certificate generation |
PDF certificates with student name, level, date, unique serial number, and QR code for public verification (no login required). Transcript PDF with all subjects, scores, weighted grades, and tiers. Eligibility check prevents generation for incomplete students |
New |
| Chatbot (FAQ + Escalation) |
No chatbot |
FAQ bot with keyword matching and category filtering. Multi-language support (EN/FR/SW/PT). Escalation to human support when FAQ cannot answer. Image upload during escalation. Tables: tbl_chatbot_faq, tbl_chatbot_escalations |
New |
| Student Achievements |
No achievement tracking |
Admin can add student achievements, recognitions, and awards with free-text descriptions. Stored in tbl_student_achievements |
New |
| Executive Dashboard |
No analytics dashboard |
Flutter analytics app with public overview (no auth) and authenticated detailed reports. Enrollment trends charts (fl_chart), performance metrics, territory breakdown. Day/night mode |
New |
| Mobile App |
No mobile app |
Flutter student app with 9 screens: registration, login, dashboard, subjects, assignments, exams (online + downloadable), performance/grades, chat, chatbot, profile. Plus push notifications via FCM |
New |
| Data Integrity Module |
No automated integrity checks |
Partial UNIQUE indexes on active records (Flyway V7). BOM cleanup triggers. Daily scheduled integrity checks logged to tbl_data_integrity_log. Schema management admin page with fix-duplicates, export, and backup operations |
New |
3.9 User Experience & Interface
| Feature |
Legacy System |
New Platform |
Status |
| Web Admin |
JSF/PrimeFaces (legacy Java-based UI, Apache Ant build) |
Next.js 16 with TypeScript and Tailwind CSS 4. App Router architecture. 35 pages across 4 roles. Modern responsive design |
New |
| Day/Night Mode |
No dark theme |
Dark theme across all three apps (mobile, executive dashboard, web admin). SA branding colors preserved. Theme preference persists across restarts. Toggle via settings/nav bar |
New |
| Internationalization (i18n) |
English only |
4 languages: English (EN), French (FR), Kiswahili (SW), Portuguese (PT). All UI labels, messages, and error texts translated. LanguageTranslator for runtime switching. Message bundles in src/main/resources/ |
Enhanced |
| Profile Update |
Limited profile editing |
Full profile update: first name, middle name, last name, email, phone, marital status, session preference, Salvation Army rank. Non-editable fields (admission number, territory) locked. Available on both web and mobile. Unique field validation enforced |
Enhanced |
| Chat System |
Basic chat |
Real-time chat between students, tutors, and admins. Unread message count. Full message history persistence. Available on both web and mobile. Stored in tbl_chat |
Enhanced |
| Notifications |
Basic SMS notifications |
Configurable notification channels: SMS, Email, Push (FCM), SMS+Email, or All. Channel selection via System Settings. SMS logged in tbl_sms_log. Push notifications via Firebase/Django relay. System announcements visible on dashboards |
Enhanced |
3.10 Infrastructure & Operations
| Feature |
Legacy System |
New Platform |
Status |
| File Storage |
Filesystem only at /opt/salt_files. Territory-based directories (+254/, +250/, etc.) |
MinIO (S3-compatible) with dual-read fallback adapter. New uploads go to MinIO. Existing file references still resolve via filesystem fallback. Territory-based path structure preserved |
New |
| Caching |
No caching layer |
Redis 7 with named caches and configurable TTL. Configuration in CacheConfig.java. Used for sessions, lookups, and frequently accessed data |
New |
| Database Migrations |
No migration framework — manual SQL scripts applied ad-hoc |
Flyway with 7 versioned migrations (V1–V7). Baseline-on-migrate enabled. Additive only — no drops or renames. Auto-applied on application startup |
New |
| Containerization |
Manual server setup |
Docker Compose with PostgreSQL 17, Redis 7 (Alpine), and MinIO. Persistent volumes for data. One-command infrastructure startup |
New |
| Integration Testing |
No integration tests |
Testcontainers for integration testing against real PostgreSQL, Redis, and MinIO instances |
New |
| Reports & Export |
Basic reporting with limited export |
Comprehensive reports: enrollment trends, assignment analytics, exam performance, territory breakdown, student tallying, marking progress. Export to Excel (Apache POI) and PDF (OpenPDF) |
Enhanced |
4. Production Bug Fixes
Nine production bugs were identified and fixed as part of the overhaul. These bugs affected core workflows including registration, approval, search, and data integrity.
| Bug # |
Description |
Affected Area |
Root Cause & Resolution |
| 1 |
Post-approval profile missing data |
Student Profile |
After admin approval, student profile displayed incomplete data. Root cause in CommonService.getDefaultUser() returning insufficient fields. Fixed to return complete biodata including all demographic fields |
| 2 |
Mobile registration failures |
Registration |
Student registrations from mobile devices failed silently. Root cause in AutenticateController.java registration endpoint not handling mobile request format. Fixed to support mobile client payload format |
| 3 |
Auto-capture registration number for continuing students |
Enrollment |
Continuing students received "NA" as their registration number instead of their existing admission number. Root cause in CommonService.getDefaultUser(). Fixed to auto-capture and preserve existing admission number |
| 4 |
ETO cannot find continuing student enrollment |
ETO Approval |
ETO could not locate continuing student enrollments in the approval queue. Fixed search and filter logic to include continuing student entries alongside new students |
| 5 |
Student performance records vanished after marking |
Marking |
After tutor marked assignments, student performance records disappeared from the system. Fixed data persistence logic to prevent record loss during marking workflow |
| 6 |
Challenges approving specific student |
Admin Approval |
Certain student records could not be approved due to data validation issues. Fixed approval flow to handle edge-case data patterns |
| 7 |
Student "not fully enrolled" + email anonymized |
Enrollment |
Specific students (Esther Mwangale, Tebogo Nkotane) shown as "not fully enrolled" despite completing registration, and their emails were anonymized. Fixed enrollment status resolution and email display logic |
| 8 |
Assignment upload date mismatch (wrong month) |
Assignments |
Assignment date filters showed incorrect month (off-by-one error). Fixed date handling in AssignnementService.java to match actual upload timestamps accurately |
| 9 |
Account locked after approval |
Authentication |
Student accounts were locked immediately after admin approval, preventing first login. Fixed account activation logic to ensure accounts are accessible after approval |
5. Database Changes (Flyway Migrations)
Backward Compatibility
All database changes are additive only. No tables or columns were dropped or renamed. All existing data and ID formats are preserved. Migrations are applied automatically on application startup via Flyway with baseline-on-migrate enabled.
| Migration |
Purpose |
Details |
| V1 |
Create sequences for new tables |
Dedicated sq_* sequences for sessions, grading configuration, billing, billing items, certificates, suspension log, intake configuration, student achievements, chatbot FAQ, chatbot escalations |
| V2 |
Create new tables |
Tables: tbl_sessions, tbl_grading_config, tbl_billing, tbl_billing_items, tbl_certificates, tbl_suspension_log, tbl_intake_config, tbl_student_achievements, tbl_chatbot_faq, tbl_chatbot_escalations |
| V3 |
Add columns to existing tables |
Added session_id to tbl_student. Added suspension fields and retake fields to tbl_student_subjects_selection. Added downloadable/deadline fields to tbl_exam_paper. Added grading/assignment/notification parameters to tbl_sys_settings |
| V4 |
Create performance indexes |
Added indexes on frequently queried columns for improved search and filtering performance across student, enrollment, and exam tables |
| V5 |
Seed default grading configuration |
Inserted 6 grading tiers into tbl_grading_config: High Distinction (85-100), Distinction (75-84.99), Credit (65-74.99), Merit (55-64.99), Pass (50-54.99), Fail (0-49.99) |
| V6 |
Additional schema updates |
Continued additive improvements to support Phase 3-7 features |
| V7 |
Data integrity constraints |
Partial UNIQUE indexes on active records (prevents duplicate active admission numbers). BOM cleanup triggers (remove_bom(), remove_bom_on_users()). Audit trail support for admission status changes |
6. Architecture Comparison
Legacy Architecture
Browser (Desktop Only)
|
v
JSF / PrimeFaces Frontend (Apache Ant build)
|
v
Spring Boot 3.3.3 (port 8091, /SaltELearnAppApi)
|
+-- Basic JWT Auth (jjwt 0.6.0)
+-- REST Controllers + JSF Views
+-- Service Layer
+-- JPA Repositories
+-- PostgreSQL 17 (salvation database)
+-- Filesystem (/opt/salt_files)
|
X-- No caching
X-- No migrations
X-- No containerization
X-- No mobile app
X-- No analytics dashboard
New Architecture
+-----------------------+ +-------------------+ +---------------------+
| Next.js 16 Web | | Flutter Mobile | | Flutter Executive |
| Admin (port 3000) | | App (Student) | | Dashboard |
| 35 pages, 4 roles | | 9 screens+chatbot | | Analytics + Charts |
| Tailwind CSS 4 | | Riverpod 3.x | | fl_chart, Riverpod |
| Day/Night Mode | | Day/Night Mode | | Day/Night Mode |
+-----------+-----------+ +--------+----------+ +----------+----------+
| | |
+----------+-------- ------+----------------------------+
|
v
+--------------------------------------------------------------+
| Spring Boot 3.4.2 API (port 8091, /SaltELearnAppApi) |
| +-- JWT Auth (jjwt 0.12.6, HS256, OTP, Brute Force) |
| +-- 15 REST Controllers (v1 + v2 stubs) |
| +-- 27 Services (Grading, Billing, Suspension, Certs...) |
| +-- 48 JPA Repositories |
| +-- Flyway Migrations (V1-V7, auto-applied) |
| +-- i18n (EN, FR, SW, PT) |
+------+------------------+------------------+-----------------+
| | |
v v v
+--------------+ +---------------+ +---------------+
| PostgreSQL | | Redis 7 | | MinIO |
| 14 | | (Alpine) | | (S3-compat) |
| salvation DB | | Named caches | | salt-files |
| 35+ tables | | TTL config | | Dual-read |
| Flyway V1-V7 | | Sessions | | Fallback: FS |
+--------------+ +---------------+ +---------------+
|
+--- Docker Compose (one-command startup)
+--- Testcontainers (integration tests)
7. Summary Statistics
New Feature Summary
| Category |
New |
Enh. |
Fixed |
| Authentication & Security | 1 | 5 | 0 |
| Student Registration & Enrollment | 3 | 3 | 1 |
| ETO & Admin Approval | 3 | 2 | 1 |
| Subject & Curriculum Management | 1 | 3 | 0 |
| Assignment Management | 4 | 0 | 1 |
| Exam Management | 4 | 2 | 0 |
| Grading System | 1 | 3 | 0 |
| Entirely New Modules | 8 | 0 | 0 |
| User Experience & Interface | 2 | 4 | 0 |
| Infrastructure & Operations | 4 | 2 | 0 |
| TOTAL |
31 |
24 |
3 |
Backward Compatibility Maintained
All changes were implemented with full backward compatibility with the production salvation.sql database. No tables or columns were dropped or renamed. All existing ID formats (admission_no, subject_code, territory_code) are preserved. The MinIO dual-read adapter ensures existing file references continue to resolve. The platform is ready for User Acceptance Testing (139 test cases across 25 categories).
© 2021-2026 College E-Learning — Feature Comparison: Legacy System vs New Platform
Version 1.0 | 20th February 2026
© 2021-2026 College E-Learning — Developed by Sumba Group Limited for Salvation Army SALT College of Africa