Time to Read: 4 MinutesComments
In the last post on the data migration process for migrating the existing information from the old system to the new system; I covered the first 6 of 17 stages of the migration process which covers the creation of the organizational structure (e.g., department, programs, courses, terms, campuses) of the institution inside of the new system and migrating all of the content-related information from the old system to the new system (e.g., schools, institutes, students, faculty, clinical instructors, student tests, and more). The data migration process follows a specific order to ensure that relationships between related components are correctly constructed. An object which depends on a reference to another object is not created before the latter object is created and so forth. Also, given the nature of the information within the old system many actions were taken to format, sanitize, and ensure the accuracy and consistency of the information that was migrated over to avoid redundancy and unintelligible information. The information essentially had to be broken down, cleaned thoroughly, and restructured for the new system’s database structure.
Once the content information had been migrated over, the next is the migration of Admission Tracking System Information.
A late-comer feature of the old system, the admission tracking system was developed in the old system alongside the development of the new system. As the popularity of the old assessment system grew, it began to take on new responsibilities, one such responsibility was the tracking of admission-related information and statuses for graduate programs for reporting purposes.
This information depends on the existence of prior migrated student and program information.
This migration involved moving data from the following tables in the old system:
Into database tables in the new system such as:
A lot of the data in the old system was fairly clean and structured in a manner that allowed for an easy transition to the new system.
Similar to the organizational information, user role information wasn’t held in the database of the old system and much of its information (i.e., user roles and their permissions) were hard-coded in the source itself. Therefore, this migration doesn’t involve actually migrating anything but simply creating the user roles and their permissions and other details based upon the hard-coded information in the old system.
The main stages of this process was:
Creating the user role it self. This involved mainly outlining the details such as the user role’s title and template (e.g., student, faculty, clinical instructor). However, there were some minor changes to be made such as:
All of the above details were taken from the source of the old system. This information was also dependent on the prior creation of program information from the first step of the migration process.
One of the bigger migrations, larger than all of the content-related information, is the migration of the historical enrollments information. Largely consisting of migrating all of the information contained in three separate tables in the old system responsible for holding all historical enrollment information differing by minor details (i.e., placement or none placement and programs) into one table in the new system responsible for holding all centralized enrollment information. Thankfully, the process was fairly straightforward and the information did not require too much white-listing and sanitization. The structure of the table in the new system was very similar to the a star schema and therefore the majority of the fields simply referenced rows in other fields so a multitude of look-ups were required when migrating a row of enrollment information.
Similar to the user role information, none of this information was stored within the database of the old system and was primarily the concern of the source code itself. However, in the new system this behavior was moved out of the code and into the database allowing it to change without the modification of the source code itself (which was responsible simply for interpreting and executing upon the information stored in the database).
This creation process constituted of a few steps:
The above 4 steps in the migration process essentially set up the information in the new system that would be critical for these next steps in the migration process; namely, the migration of the assessment data itself (the largest step) and other enrollment-bound information. Those steps will be covered in future posts.
This post is about the project, DREAM
An online electronic assessment system for the purpose of collecting assessment data regarding student teachers and counselors throughout their collegiate career. The system also electronically facilitates a large number of other institutional processes in an effective manner.
Software Developer Career Tips: Closing Thoughts
12 February, 2020
Fitness Series: Illnesses and Injuries, Make a Contingency Plan
03 February, 2020
Software Developer Career Tips: The System Design Phase
27 January, 2020
Software Developer Career Tips: The Technical Phase
21 January, 2020
Software Developer Career Tips: Do Your Preliminary Research
13 January, 2020
The Power of Habit
19 December, 2019
Rich Dad Poor Dad
14 October, 2019
19 August, 2019