Migrate from Tribune to Bullhorn ATS & CRM

Tribune Subscriber is the primary identity object and maps 1:1 to Bullhorn Candidate. We preserve firstName, lastName, email, phone, and street address from the Tribune subscriber record onto the Bullhorn Candidate record. Name fields are split into first and last name during import. If the Tribune record uses a single display name field, we split on the last space as the default rule, with a reconciliation pass for records that fail the split. The Candidate's email address becomes the primary dedupe key.

Tribune's 77 daily and 150+ weekly publication titles have a many-to-many relationship with subscribers. Bullhorn Candidate does not natively support a publication-subscription association. We map each publication title to a Bullhorn custom Text field on the Candidate record (up to 55 fields per custom object on Front Office Growth/Enterprise; 2 on Bullhorn ATS; none on ATS Growth). For subscriptions spanning many titles, we recommend a separate Publications custom object linked to Candidate via a lookup relationship, with a junction table mapping subscriber-to-publication.

Tribune subscription tiers (print-only, digital-only, bundled) have no direct Bullhorn equivalent. We map tier names and rates to a custom Candidate field (e.g., subscription_tier__c as a picklist) or a custom object storing tier metadata. If the customer uses Bullhorn's Opportunity object for commission tracking, tier can also map to a custom Opportunity field. Bullhorn's picklist values are configured during setup.

Billing records from Tribune include payment method type, billing frequency, and transaction history — but payment card data is tokenized or masked and cannot migrate. We create a custom object SubscriptionBilling in Bullhorn linked to the Candidate record via lookup. Fields include billing_frequency__c, last_charge_date__c, last_charge_amount__c, next_renewal_date__c, and subscription_status__c. Auto-renewal status migrates as a checkbox or picklist flag for billing team audit.

Tribune auto-renewal flags identify subscribers whose promotional rates will convert to standard rates at next renewal — a billing event that triggers charges in the source system. We migrate the auto-renewal flag to a custom Candidate field (auto_renewal_enabled__c) and generate a separate Auto-Renewal Flag Report listing all migrated candidates with auto-renewal active and their effective renewal dates. This report is handed off to the billing team for pre-cutover audit.

Tribune print delivery addresses migrate 1:1 to Bullhorn Candidate address fields (address, city, state, zip, country). Records with active temporary forwarding instructions are flagged in the import scoping phase with a temporary_address_note__c field so the billing or fulfillment team can process forwarding separately. Address deduplication rules are applied during import using fuzzy matching on street + zip.

Tribune subscription preferences (delivery frequency, format, notification opt-ins) map to Bullhorn custom Candidate fields. We create picklist fields for delivery_frequency__c (daily, weekends, selected_days), format_preference__c (print, digital, bundled), and notification_opt_in__c (boolean). These are created during Bullhorn schema setup before record import.

Digital subscriber portal access credentials are mapped to a custom Candidate field (digital_access_tier__c) indicating which tier of online content access the subscriber holds. Full credential migration (username/password) is not performed as Tribune credentials are platform-specific and not portable to Bullhorn. The field documents the access tier for the receiving team to provision equivalent access in their own system.

Bullhorn's Client Corporation object stores company clients that post jobs and receive placements. Tribune's data model has no direct equivalent. If the receiving team plans to use Bullhorn for recruiting, Client Corporation records are created manually or through a separate company import from the customer's existing client list. We include a Client Corporation setup guide in the migration deliverables for the admin to populate post-migration.

Bullhorn Job and Job Order objects have no Tribune equivalent. These are populated post-migration as the staffing team begins placing candidates. We do not pre-create jobs from Tribune data because Tribune publishes news content, not job postings. The migration delivers a Bullhorn Jobs setup guide as part of the handoff package.

Bullhorn Placement records track placed candidates, start dates, pay rates, and bill rates. These are created during active recruiting operations post-migration and have no Tribune equivalent. The migration does not pre-create placements.

Tribune group enterprise subscriptions (companies, universities, libraries sharing a subscription) map to Bullhorn Client Corporation records with a linked custom object (GroupSubscription) capturing the enterprise account number, total seat count, and renewal date. This handles the one-to-many relationship where a single enterprise subscriber covers multiple individual records.