1. Copyright Mary Cauble, Michael Farris, Whitten Smart, Jeff Snider 2009
Copyright Mary Cauble, Michael Farris, Whitten Smart, Jeff Snider This work is the intellectual property of the author(s). Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author(s). To disseminate otherwise or to republish requires written permission from the author(s).

2. From Blackboard to Sakai
The Who, What, Where and Why
EDUCAUSE Southwest Regional Conference 2009
San Antonio, Texas

3. Michael Farris, Project Lead Whitten Smart, Training/Documentation
Presenters
Michael Farris, Project Lead
Whitten Smart, Training/Documentation
Jeff Snider, DBA/Developer
Mary Cauble, Change Management

4. It was heavily modified and aging by 2004. Things had changed.
The Predicament
Blackboard adopted in 1999
It was heavily modified and aging by 2004.
Things had changed.
Texas State adopted Blackboard in 1999.
Initially, Blackboard contained 25 course sites created by 18 faculty members and served approximately 200 students.
Over the years, Texas State’s version of Blackboard had become more and more customized in order to meet the particular needs of its faculty and students.
By 2004, the university’s highly customized version of Blackboard contained over 8,000 course sites created by over 1,300 faculty members and served all 24,000+ students.
Texas State University was faced with supporting a heavily modified, aging version of Blackboard.
 Migrating to a newer version of Blackboard would require a complete rewrite of the custom code that supported features faculty relied upon, and each future release of Blackboard would require the same rewrite.

5. The Project
To deactivate the customized version of Blackboard by facilitating a voluntary migration of faculty to a more robust, agile learning management environment.
Provide a learning management system that:
Placed control in the hands of the people who use it, Texas State faculty; and
Supported the development and maintenance of customization with minimal restrictions.

6. Documented current feature set Interviewed faculty
The Beginning
Documented current feature set
Interviewed faculty
Likes, dislikes, wants
Completed a gap analysis

7. Critical Success Factors
Blackboard import of course sites
Voluntary migration of faculty
Perceived benefit to faculty
Measures of success
100% of the course sites in BB could be moved to the new environment
95% of faculty would voluntarily migrate to the new environment
80% of faculty would believe that the new environment was more beneficial than the old one.
Course sites in Blackboard 5.5 could be moved to new system
Faculty users voluntarily migrate to new environment
Deployed environment could be extended with core code being continually updated
Modification implemented in TRACS were shared with Sakai community
Development and modifications would be compatible with Sakai’s core code
Presentation layer would be accessible to all major browsers and ADA compliant

8. Application Development Network and Server Infrastructure
Project Skill Sets
Application Development
Network and Server Infrastructure
User Involvement and Change Management
Branding and Positioning
Support Structure
Training and Documentation
Quality Assurance
Sakai Foundation Tracking and Advocacy

9. A shakedown of the system and processes was the goal, not perfection.
The Pilot Overview
A shakedown of the system and processes was the goal, not perfection.
Recruit 1,000 users
Develop initial branding
Develop visual identity pieces
Skin TRACS
Develop brand essence
Develop branding guide
Develop strategy for features
Define feature list
Develop a process for introducing features
Explore usage patterns and push alternatives
Create demand for TRACS
Create public web site
Create traveling road show
Create basic communications
Train content providers
Add content to website
Demo TRACS
Develop communication plan
Determine domain name
Create proactive support structure
Maintain and expand website
Develop two-tier handholding strategy
Deploy migration support documents sessions
Develop browser solution
Create Q/A plan
Create effective training
Deploy workshops and curriculum
Develop flash tutorial
Develop training schedule
Develop quick start guide
Develop course creation guide
Develop Blackboard, TRACS inter-application interface
Develop BB archive import
Deploy BB-TRACS cross-linking
Develop send tool
Deploy shared authentication
Sync with registrar
Be ready for faculty
Perform readiness check for pilot group
Identify static content for TRACS
Perform backups

10. The Pilot Change Management
Faculty selected for pilot based on identified characteristics
Fall 2005
10 faculty, about 900 students
Spring 2006, Summer 2006
25 faculty, about 2000 students
Pilot was personal
Executive Support
Provost
Vice Presidents
Assistant Vice Presidents
Deans
Faculty Involvement
Chairs
Faculty Senate
Faculty interviews
Departmental Liaisons

11. One-on-one faculty training In class training Documentation
The Pilot Support, Fall 2005
Handholding
One-on-one faculty training
In class training
Documentation
Phone and
Instructors were new to the system and had never seen it before. We stepped them through the entire process of course creation and the various tools they wanted to use. We explained what each tool did and allowed instructors to choose their tools based upon the description.
We trained the faculty members in one hour sessions in their offices on their own computers and familiar environment to reduce stress
Training was also extended to the students in the classroom via in class demonstrations of the system.
Support staff began writing customized documentation for Texas State audience
Support questions were also

12. Workshops TRACSfacts OTRS Beginning Advanced Gradebook and Assessments
The Pilot Spring, 2006
Workshops
Beginning
Advanced
Gradebook and Assessments
TRACSfacts
OTRS
We began creating a workshop curriculum for implementation later in the semester and for future semesters. We offered 3 different workshops (Beginning, Advanced, and Gradebook and Assessments) each lasting 2 hours long.
We created TRACSfacts, a site to serve support information as well as information about the project. Users can go to the site and download documentation and training materials as well as view other various helpful materials such as the TRACS readiness survey and the Blackboard tool name conversion chart
Implemented ticketing software called OTRS which creates tickets for user’s issues and provides tracking so that issues don’t fall through the cracks

13. The Pilot Lessons Learned
What worked
Targeted identified faculty groups
Created TRACSfacts web site
Busted myths
Branded Sakai
Ooops
Learned that “We are not the user”
You can use TRACS on a MAC

14. Are we ready? Decide: Faculty readiness survey
The Migration Begins
Are we ready?
Decide: Faculty readiness survey
Prepare: Curriculum for workshops and documentation
Encourage: Push and pull of features
Migrate: Blackboard archive import

15. The Migration Begins Overview
Decision to open access to faculty and staff for TRACS
Too many people knew about the system and were asking to join.
We had to open the doors .
We had the blackboard import tool working.
We also had the readiness survey that told users if they were ready or not to use TRACS

16. The Middle Years Overview

17. The Middle Years Spring 2007 – Spring 2008
Focused on reliability
Became more proactive in Sakai community
Expanded support efforts
Involved faculty in core team
Faced the FUDs

18. The Middle Years Change Management
Informed academic chairs
Targeted communications
Trained Teaching Assistants
Tracked migration
Routed new faculty
Published BB end date
Used MOTD for contextual communication
Every semester we sent messages to all faculty. “here is TRACS, there are workshops, we are here to help you, how can we help you…”
A special communication was drafted and sent to the TA’s.
In Spring, 2007, we had a 55% participation level in TRACS; by Fall 2007 we had a 72% participation level.
In November, 2007, we informed the chairs that new faculty would not be allowed to create course sites in Blackboard for Spring 2008 courses. We would only provide TRACS training for new faculty.
In Early Spring 08 the decision to not allow creation of Fall 08 courses in BB was announced. Throughout the Spring 2008 semester we continued to inform the campus of the decision to support TRACS exclusively in Fall 2008.
Additionally, in the 2008 spring semester, we sent to all chairs listing those faculty who still used Blackboard exclusively. We reviewed the list of faculty still using BB exclusively and classified each individual (procrastinator, fearful, curmudgeons). We also sent different messages to the individual faculty members based on their “classification” offering help, asking what was keeping them from migrating, etc.

19. The Middle Years Change Management
Faculty Steering Committee
Role
Criteria
Support
Expectations
By Fall 2006, our liaisons were falling away and we re-evaluated that whole process and decided to “dismiss them” and instead organize a steering committee of individuals we knew that were really committed to using TRACS. We would keep close contact with them, inform them of upcoming changes, solicit their opinions on changes, improvements, ideas, suggestions and so on.
This turned out to be a smaller, but far more successful and useful group
Steering committee was formed consisting of faculty members from various departments on campus.
Their role was to serve as the first point of contact in their department and kill any negative buzz due to misinformation.
Steering committee members were selected based upon the computer knowledge, extensiveness of their Blackboard sites, and tool selection in Blackboard.
Steering committee members were supported via phone, , and one on one meetings
serve as a liaison between faculty and the system, provide faculty feedback, and serve as a disseminator of information to their department

20. The Middle Years Support
Workshops
Training videos
TRACSfacts Re-vamp
Faculty-to-faculty help
FAQ
During the Middle years we gave 90 workshops and had over 1000 faculty, TAs, and GAs attend them. The workshops were still 2 hours long and covered the same 3 topics.
Offered tool specific workshops as well as beginning of the semester “refresher” courses
Totally re-made TRACSfacts. The site now turned away from “selling” the system to be more support oriented. TRACSfacts became the one stop shop for training materials, workshop schedules and sign up. The site also was split into Student and Faculty/Staff areas.
Short training videos were added to the site for on demand training
Started offering online workshops using Connect for people at other campuses
Faculty to Faculty help was added to TRACSfacts. These were a series of videos in which instructors using the system talked about how they used TRACS and the benefits of the system.
FAQs were added to TRACSfacts

21. The Middle Years Lesson Learned
What worked
Recognized the need to tailor communications
Offered diverse forms of training
Involved faculty in decisions
Ooops
No software releases before finals
Acknowledge the obvious
Managed to add a faculty member from the English Department to the project team.
Needed to remember to take functionality questions, user interface questions, workflow questions, etc to the faculty steering committee
Steering committee said faculty want/need to know the end date of bb
No changes to Gradebook!!!!!!
It’s bigger than you think, own up to your mistakes - quickly

22. The Final Days Summer 2008

23. The Final Days Overview
Focused on last 5% of faculty
Focused on staff sites
Implemented progressive shutdown of access to Blackboard
By Summer 2008 we had approximately 50 faculty still using BB exclusively.
Among the 50 were faculty using courses created by our instructional designers, faculty going to another university in the fall, faculty with course cartridges, and faculty who were retiring in the fall; this left us with 38 “hangers-on.”

24. The Final Days Change Management
Returned to one-on-ones (The Smile Curve)
Handholding
Telephone calls
Office visits
Insured that administration was informed

25. Increased support staff Conducted fewer workshops Implemented Bomgar
The Final Days Support
Increased support staff
Conducted fewer workshops
Implemented Bomgar
Improved coordination with campus helpdesk
Deployed new telephone system
Increased support staff by 2 people.
Conducting fewer workshops, more focus on beginning of semester. Workshops shift to refresher sessions and tool specific workshops instead of full workshop gamut.
Training videos for students and faculty roles in TRACS showing users step by step instructions
Implemented Bomgar software that allows support staff to remote into user’s personal computers and see exactly what the user sees
Increased coordination with the campus helpdesk to define expectations, resolutions, and communication

26. The Final Days Lessons Learned
What worked
Recognized that happiness is not 100%
Acknowledged the dark side and did the opposite
Went slow, stayed low, kept moving, didn’t get too greedy
Tracked the last 5%
Ooops
Remember the orphaned users
No software releases during anxious times in the academic calendar
Remember the students
Non-traditional users – Correspondence
The lengthy migration period was hardest on the students (using 2 systems)

27. We have never used Sakai “out of the box”
Development Overview
We have never used Sakai “out of the box”
It’s editable because it’s open source. A good thing, and a bad thing.
New features and tweaks to assessments, assignments, gradebook, forums, and many others.
New versions take a lot of work.

28. Two major components had to be added
Development Overview
Two major components had to be added
Authentication handler
Course registration data
Originally this was a custom “Course Management Provider.” When upgrading to 2.4, we switched to using the built in CMP. Much simpler, less code changes to maintain.

29. Infrastructure Overview
For pilot, we used virtual machines
Flexible
Slow (Many years ago. VM performance is better now)
Physical hardware for open migration.
Clustered app servers allow for rolling restarts
32 bit vs 64 bit

30. Infrastructure Growing Pains
Discovered early on that app servers are fragile. Use LOTS of them.
Database setup. Worth getting it right the first time
UTF8
MyISAM
System has grown organically as needed to keep up

31. Infrastructure Current Setup
12 application instances
New ones are 64 bit, replacing older ones
New app instances use 4Gb of RAM each
Database
Big n’ honkin’
14Gb setup for MySQL
Don’t cheap out on this. If you can only pick one place to spend most of your cash, this is it.
Growable file store
Consuming storage at ~2Gb per day

32. Define archive retention process Increase involvement of users
Next Steps
Define archive retention process
Increase involvement of users
Focus on pedagogy
Deploy a knowledge base
Create task-based help
Deploy Sakai 3

33. Questions and Answers

34. Appendix The Project Team
Michael Farris – Project lead
Rori Sheffield – Project Assistant/User Support
Salwa Khan – SAKAI liaison/User Involvement
Jeff Snider – DBA/Developer
Amy Boyd – Developer/Programmer
Sean McMains – Software Architect and Advisor
Yuanhua Qu – Developer/Programmer
James Buratti – Web Support
Jimmy Rico – User Support and Documentation
Whitten Smart – User Support and Documentation
Mary Cauble – Project & Change Management
Laura Trial – Graphic Design
Deborah Morton – Faculty Representative
Vacant Position, to Be Filled – Quality Assurance
14 staff; 3 were devoted full time to the migration and on-going support of Blackboard

35. Appendix The Pilot Infrastructure
Pilot system
Virtual, since we didn’t know what we needed
What worked
Apache &mod_jk
Multiple app servers
What didn’t work
Files stored in DB
So few app servers (They die a lot)

36. Appendix The Migration Begins Infrastructure
Open Migration System
What changed
Real hardware
Several instances of the app per server
Separate storage for files
What didn’t work
Cheap network switches that failed under load gave us a big black eye at the start of semester

37. Appendix The Middle Years Infrastructure
By Spring 08, average daily sessions had risen from 700 to 2500.
Added another server capable of running four more instances of the app
DB server load is consistently high, so we submit a request for a new server

38. Appendix The Final Days Infrastructure
New DB server finally comes in. One day before the start of Fall.
Old DB server is overworked.
We tried to wait until a weekend to upgrade -- Mid-week upgrade decided for us.
New DB server is huge. Tuned for speed. MySQL allocated 12Gb.