When hundreds of thousands of Canada geese migrate from central Canada to Wisconsin and further south for the winter months, they are triggered by built-in mechanisms that tell them when to migrate, in which direction, and how far. Other factors like body fat, magnetic fields, the stars, and the sun influence the path the birds take to carry out their eating, nesting, and mating cycles. Oh, if a pattern like this were that clear and inherent when we talk about migrating resumes from one system to another! It would save recruiting and IT organizations a lot of time, money, and effort. But when organizations are the proud owners of a fat resume database (see my article How Big Is Your Black Hole?), implementation teams are faced with the pivotal question of whether to migrate or not to migrate resumes and other legacy data. The “migration” question has been asked ever since the first companies put resumes in one repository and then decided to change systems. Here are some of the most commonly asked questions in the migration-decision process:
- Should we bring the resumes over to the new system?
- If so, should we bring all or just part of the resumes?
- If just part, which part? Based on creation date? Based on attachment to an active requisition? Based on geography or job family? Or some combination of all these?
- Is our desired criteria extractable from the existing database?
- Are the desired fields of data importable into the new system?
- If we choose to bring over resumes on or after a certain date, which should it be: all the resumes, last three months, last six months, last year?
- Should we filter in or out college-specific resumes?
Breaking down the factors in this decision-making process can lead to a clear answer on whether to migrate, what to migrate, or whether to explore other options. Let’s take a closer look at some of these factors. Resume Volume Resume volume is the easiest variable in the decision process. How many resumes/records are we talking about: 1000, 10,000, 100,000, 250,000? How many are expected to come into the new system on a weekly/monthly basis to replenish this supply? Check to see if there are any technical barriers to bringing over a certain amount of resumes and also if large resume databases will affect performance of system functions like searching. If not, then 10 records or 100,000 records should not make any difference. Migration-decision aid: If volume is low, say under 10,000, then it may be well worth doing a migration so there is at least some database for recruiters to use. If volume is high, over the 100,000 range, and incoming resumes are steady, then it may make sense to examine the age/value on the resumes and start filtering on certain criteria. Legacy Resume Value Often times there are different perceptions around what value the existing resume database provides to the recruiting function. I once worked with a company that was going through a spin-off, and ownership of the resume database became a key point of negotiation between the corporation and the new spin-off. The resumes were perceived as a highly valuable commodity. The terms regarding which resumes would be migrated were negotiated for months, and the company ended up migrating just the resumes attached to that division’s open positions. Judging the value of a resume database can be subjective at best if no clear metrics are kept on interviewees and hires that were clearly mined or “recycled” from the resume database as a source. The definition of a “recycle” is a resume that was entered into a database through a particular sourcing effort for a position, and without filling that position, was picked up for another position later on without any additional sourcing effort. Pure unsolicited resumes could also fall into this category. This is often difficult to capture cleanly, since the resume source (e.g., a job board or career fair) may be what’s attributed to the hire instead of the secondary “recycle” of the resume through a resume database search. If there are no clear metrics on recycled resumes, interviews with recruiters may reveal what actual value is being gained from the resume database. I’ve come across recruiting organizations in which the spectrum was very wide between recruiters who only looked at the freshest resumes and those who treasure-hunted for resumes over a year old. There are two schools of thought here. One is that any contact, no matter how old, could be a seed for another contact or source and could turn into a lead. Another is that resumes without dated addresses, phone numbers, and emails are basically useless. Certainly more skill is needed to obtain value out of the older resumes. Migration-decision aid: If recruiters are not working with older resumes in the current system, chances are they may not work with older resumes in the new system even with improved search functionality. If migrating, you may want to look at shorter-term date parameters, such as two to six months. Which Resumes To Migrate Criteria, as discussed above, can be date parameters, but can also include other factors. Extracting the exact resumes based on some of these factors will depend on the abilities of your current system and database as well as the ability to write the detailed extraction script. Other criteria include:
- College/university
- Geography (e.g. country-specific filter in/out)
- Source (e.g. agency filter in/out)
Migration-decision aid: Being able to extract on more detailed criteria will mostly be dictated by your organization’s ability to isolate the resume grouping at the database level. Keeping it simple whenever possible is the best approach; however, there may be circumstances where filtering resumes in or out for business reasons may make sense. Keep in mind, if you’re between campus recruiting seasons, college resumes may have the shortest shelf life. What Resume Data Is Important? Once you’ve determined which resumes you want to migrate, determining what parts of the data record and the resume to migrate is the next important step. Here are some factors in this decision:
- Does your system have .txt and image files of the resume? Do you want to bring over both?
- Do you need the history and req associations of the candidate, and is this information that will go into the new system?
- Do you want multiple versions of the candidates resume if the current system supports that?
- Do you want source information?
Migration Alternatives Here are some alternatives to a resume migration that should also be discussed during this decision-making process:
- Don’t do anything. Let the resumes go to the system graveyard and use your new system launch as an opportunity for a corporate branding campaign that helps drive new candidates to your website.
- Direct mail campaign. Do a targeted extraction of just the contact data on a group of resumes, say from six months or one year back. Send out either an email or postcard that advertises the new website or other method to get to the new system as well as the benefits of reapplying. Investment may be high if doing a postal mailer, and return may be low (under two percent). But there may be branding benefits here as well.
- Recruiter scrub. Put the burden on the recruiters to search and extract who they want from the current database before it gets turned off. Set up an easy process and a timeframe (perhaps a few months) with a “new system” email to which they can easily send the records they want to be imported or entered into the new system. Provide countdown messages as the weeks go by to encourage the scrubbing process.
When deciding on resume migration, all these factors should be examined before making the assumption that the whole database (or none of it) should be moved over to the new system. The proof is in whether these resumes and records will actually be used and acted upon when the new system and process are in place.