Data Migration Studio — Guided Walkthrough

Connect two pre-seeded demo databases and run a real migration into PulseServe.

The sandbox ships with two disposable, pre-seeded "legacy client system" databases so you can try Data Migration Studio end to end — one relational (PostgreSQL), one schemaless (MongoDB). Both connect with a read-only account: you can run the full flow, including a real migration, without any risk of changing the fixture itself.

Connect the PostgreSQL source

  • Host: legacy-itsm-demo
  • Port: 5432
  • Database: legacy_itsm
  • Username: legacy_reader
  • Password: legacy_reader_dev
  • TLS mode: Disabled

Connect the MongoDB source

  • Connection URI: mongodb://legacy_reader:legacy_reader_dev@legacy-mongo-demo:27017/legacy_helpdesk

Suggested walkthrough

  1. Add a data source, pick PostgreSQL, and enter the credentials above. Test the connection.
  2. Discover the schema — five tables appear: legacy_users, legacy_cis, legacy_incidents, legacy_problems, legacy_knowledge.
  3. Generate object suggestions. The studio maps common ITSM table and field names automatically.
  4. Map legacy_incidents to Incidents, legacy_users to Users, legacy_cis to Configuration items, legacy_problems to Problems, legacy_knowledge to Knowledge articles.
  5. Add a value translation on incident/problem priority: CRIT to critical, HIGH to high, LOW to low.
  6. Run the dry-run validation, review the preview of raw vs. transformed records, then run the full migration.
  7. Repeat with the MongoDB source: add it, discover the legacy_tickets collection, and notice the documents have inconsistent shapes (some have "resolution" and "assignee", some don't) — see how field mapping handles that.

Recommended field mappings (PostgreSQL)

  • legacy_users.email to email, legacy_users.full_name to displayName
  • legacy_cis.ci_name to name, legacy_cis.criticality to criticality
  • legacy_incidents.case_no to number, legacy_incidents.short_desc to shortDescription, legacy_incidents.status_cd to state
  • legacy_problems.known_error to knownError (as a boolean transform)
Try typing a different host into the connection form instead of the ones above — it will be refused, not connected. In this sandbox, Migration Studio can only reach these two pre-approved sources no matter what's entered, which is exactly the safety property that makes it reasonable to expose this feature to a public demo at all.