Between 2007 and 2009, Missouri State University replaced its aging administrative systems with Sungard Banner ERP. Every department on campus had its own implementation lead, and I was the lead for centralized computer services user support – the group responsible for supporting all faculty, staff, and students. My contributions focused on building a Confluence wiki with over 700 knowledge base articles, creating internal communication systems for outages and status updates, and maintaining the training labs where other departments trained their teams. It was one of the most formative projects of my early career, and it taught me that the hardest part of any ERP implementation isn't the software. It's the people.
Why Missouri State Needed a Banner ERP Migration
The systems Banner replaced had all been built in-house. They were totally custom and tailored to the university's needs, but they were also very dated and getting hard to maintain. We couldn't really upgrade them, which brought its own host of problems. Because they were custom, every department had gotten exactly what they wanted over the years. That was hard to give up when moving to an ERP.
The problem was sustainability. Those legacy systems were increasingly difficult to maintain, expensive to support, and incompatible with the reporting and integration requirements the university faced. Sungard Banner offered standardized modules for student information, financial aid, human resources, and finance. But "standardized" meant the university had to adapt its processes to the software, not the other way around.
That's where the real difficulty lived. This wasn't a simple software swap. It was a fundamental change in how thousands of staff members did their daily work.
Supporting a Live Campus Migration
One thing that made this project especially challenging: the university didn't shut down while we implemented Banner. Students still enrolled. Financial aid still processed. Payroll still ran. Every department had to keep functioning with their old systems while simultaneously learning and transitioning to new ones.
We did the migration in effectively half the time that Sungard recommended. Their recommendation was either to bring on temporary staff campus-wide – not just IT, but extra people in the registrar's office, financial services, human resources, and so on – to give us the capacity to keep serving students while doing the migration. If we couldn't bring on extra people, they recommended a timeline twice as long as what we did. We completed it on the accelerated timeline without the extra staff, and that made it especially intense.
As the lead for centralized user support, I was one of many departmental leads working on this project. My role focused on the infrastructure that helped everyone else do their work: advising on technical considerations, building communication systems so campus knew when something was down or changing, and making sure the training labs and tools were ready for the departments running their own training sessions.
The coordination wasn't glamorous work. It was scheduling, follow-up, and documentation. But the support infrastructure mattered because every other lead and department needed reliable communication channels and functional training environments to get their teams through the transition.
Building a Knowledge Base of 700+ Articles for ERP Training
The centerpiece of my support strategy was a comprehensive knowledge base built in Confluence. Over the course of the implementation, I authored more than 700 articles covering Banner processes, troubleshooting guides, departmental workflows, and FAQ content.
Why 700? Partially because Banner touched everything – each department needed documentation tailored to their specific use of the system. But I also knew that for the wiki to be used, we had to hit a critical mass. There had to be enough depth and enough quantity so that when people came, they would find what they were looking for. If they had a positive experience, they'd come back. We wanted this to demonstrate its value, and we also wanted to get other people involved. A financial aid counselor's interaction with Banner looked nothing like an HR specialist's. Generic training materials would have been useless – or worse, confusing.
Each article followed a consistent structure: what the process accomplished, step-by-step instructions with screenshots, common errors and their fixes, and links to related procedures. I wrote them in plain language, not technical jargon, because the audience was administrative staff who needed to do their jobs, not pass a certification exam.
This knowledge base did something that traditional classroom training couldn't: it was always available. Staff could reference it at 2 PM on a Tuesday when they hit an unfamiliar screen, not just during the training session they'd attended three weeks earlier.
One of the most gratifying experiences I had was attending a training session delivered by the head of the registrar's office in which he showed wiki articles that he had written. I didn't teach him how to write them. The wiki had just become such a part of our culture during the implementation that we went from nothing to staff writing articles themselves and sharing them with others. That's when I knew the knowledge base had succeeded.
Implementing Jira and Confluence for ERP Project Management
Before the Banner implementation, there wasn't a centralized system for tracking the project's hundreds of tasks, issues, and dependencies. I implemented Jira for project management and Confluence for knowledge sharing – tools that had only been out for a couple of years at that point, so they were pretty new in general, not just in higher education. We were some of the first users of them. This is part of why I became one of the leading experts worldwide in Atlassian tools – I've been working with them for so long and so deeply, and this project became really formative for my career.
Jira gave us visibility into what was on track and what wasn't. Implementation tasks, bug reports, training requests, and departmental readiness milestones all lived in one place. That visibility mattered because the project involved dozens of people across multiple departments, and email chains were already failing as a coordination mechanism.
Confluence became the home for the knowledge base, but also for internal project documentation – meeting notes, decision logs, architecture diagrams, and rollout schedules. Having a single source of truth reduced the "I didn't know about that change" conversations that can derail large projects.
Looking back, the choice to invest in proper project management tooling early was one of the best decisions we made. It added overhead upfront but saved enormous amounts of time in confusion and rework later.
How Training Labs and Documentation Supported the Transition
Traditional ERP training at universities often follows a classroom model: schedule sessions, pull staff away from their desks, walk through procedures in a training environment, and hope they remember it when they're back at their real workstations. It's expensive, disruptive, and has a terrible retention rate.
My role in the training effort was primarily about creating the space and tools for training, not delivering the training itself. Each department's lead handled training for their own teams. What I provided was the infrastructure: maintaining the computer labs where training happened, making sure the labs had the right software and configurations, and building the Confluence knowledge base that served as both a training reference and ongoing documentation.
The knowledge base gave every department's training effort a common resource. Staff could reference it at 2 PM on a Tuesday when they hit an unfamiliar screen, not just during the training session they'd attended three weeks earlier. And when they called support, the help desk team could walk them through documented procedures rather than troubleshooting from scratch each time.
I did track the impact of the wiki documentation on help desk support calls over time, and we saw two clear trends. First, there was around an 80% decrease in simple calls – the straightforward questions that still took time to ask and answer. Second, that freed up time for the more complex inquiries, questions, and problems that people had, which meant we were able to provide much better service and better resolutions for them.
Communication Systems and Support Infrastructure
Beyond the knowledge base, I built the internal communication systems that kept campus informed during the transition. (These eventually evolved into the help desk website that became the university's third most-viewed web resource.) When systems went down or changes were happening, faculty, staff, and students needed to know. I created outage notification processes and status update channels so the campus community wasn't left guessing.
These communication tools and the Confluence wiki outlasted the implementation itself. What started as project-specific infrastructure evolved into the foundation of the university's broader technical support and communication operations.
That wasn't the original plan. I built it to solve immediate problems – keeping people informed and giving every department's training effort a common documentation platform. But because the structure was solid and the content was maintained, it became the default way the university's IT organization documented and delivered support.
There's a lesson in that about building things properly even under project pressure. It would have been easier to throw together quick-and-dirty documentation and move on. The extra effort to create consistent, well-organized, searchable content paid dividends for years after the Banner go-live.
Lessons from Supporting an ERP Implementation in Higher Education
If I were advising someone about to support a university ERP implementation, I'd emphasize three things.
First, documentation is not optional. It's a core deliverable. Treat it with the same rigor you'd treat the technical implementation. Budget time for it. Staff it properly. Review it.
Second, the liaison role between technical teams and end users is critical and frequently understaffed. Someone has to own the translation layer between what the software does and what people need to do with it. If nobody owns that, both sides get frustrated.
Third, invest in tools early. Jira and Confluence weren't free, and they required setup and training of their own. But trying to manage a multi-year, campus-wide implementation through email and shared drives would have been far more expensive in wasted time and missed deadlines.
These lessons have shaped every large-scale project I've worked on since. The specifics change – the technology, the organization, the scale – but the fundamentals of change management remain the same.
Frequently Asked Questions
How long did the Sungard Banner ERP implementation take at Missouri State?
The core implementation was 30 months, from 2007 to 2009 – a timeline that really sticks in my head because of how compressed it was. That was effectively half the time Sungard recommended without additional temporary staff. It included planning, configuration, data migration, testing, training, and phased go-live across multiple administrative areas. The support infrastructure and knowledge base continued to be developed and maintained well beyond the initial implementation period.
What made the Banner ERP migration challenging compared to other software rollouts?
Scale and simultaneity. Banner replaced systems that touched nearly every administrative function on campus – student records, financial aid, HR, finance. Each area had its own legacy workflows built over 20 years. Migrating all of them while keeping the university operational required careful coordination and a support strategy that could flex across very different user needs.
Why was a knowledge base more effective than traditional ERP training?
Traditional classroom training happens once and fades quickly. A knowledge base is available whenever someone needs it, searchable by topic, and updatable as procedures change. For an ERP system that staff use daily in different ways, on-demand reference documentation consistently outperforms scheduled training sessions in long-term adoption.
Related Case Studies
- Redesigning Missouri State's Help Desk Website with WordPress – Another project focused on making IT support more accessible to a campus audience.
- Enterprise Fleet Management for 6,000 University Computers – Large-scale IT operations management at the same institution.
- University Domain Migration: Moving 900 Computers During a Rebrand – An earlier campus-wide technical migration project at Missouri State.