What should I verify when migrating team time entries between apps?

Treat the import as a set of records to reconcile, not as proof that every field transferred correctly. First agree on the migration scope: which people, date range, projects, and entry statuses are included. Then create a field map from the old app to the new one. At minimum, compare the entry date, duration, project or task assignment, and the person credited with the time.

Use a stable entry ID if both systems preserve or expose one. If not, define a matching key before comparing—for example, person + date + project/task + duration. That combination is only a practical matching aid, not proof that two records are the same; repeated or edited entries can collide. Set aside ambiguous matches rather than silently merging them.

Use two levels of checking. First, compare summary totals for the same scope in both apps: entry counts and summed duration by person and by week or month. These totals can reveal missing or extra records, but matching totals do not prove that the individual entries match—one missing entry and one duplicate can cancel each other out.

Second, inspect individual records. Include a sample across the beginning, middle, and end of the date range, and deliberately include unusual cases: entries near midnight, short or long durations, edited entries, and dates around any agreed reporting boundary. Check that the destination date means the same thing your team expects; note any time-zone or date-format assumptions rather than guessing. For discrepancies, record the old value, new value, and agreed action. Don’t “fix” a difference merely to make totals line up.

Compare project and task identifiers where available, not just display names. Names can be renamed or reused, so keep a mapping from each old project or task to its intended destination record, and flag anything with no clear match. Check entries assigned at different levels—project, summary, or task—if your systems support them. For example, Microsoft’s Project Operations overview describes entries tracked at task, summary, or project level; it also describes a workflow involving submission and approval. That is product-specific context, not evidence that a migration preserves those assignments or statuses [S2].

For attribution, compare the source person identifier to the intended destination user, not only a visible name. Keep an explicit mapping for renamed accounts, departed team members, and unmatched users. Do not assign an unmatched entry to the importer or a manager as a convenient default. In Dynamics 365 Project Service Automation version 3.x, the cited guide discusses fields such as project, task, and resource, but it does not explain cross-app migration or preservation of original user attribution [S1].

Use a small log alongside the comparison. For example:

Scope: [date range] | [people/projects included] Match key: [stable ID, or documented field combination] Group totals: source [count] / [duration] | destination [count] / [duration] Exception: [entry reference] | field: [date/duration/project/user] | source: [value] | destination: [value] | action: [reviewed / corrected / unresolved] Reviewed by: [role or name] | review date: [date]

Keep unresolved exceptions visible and state whether the history is ready for your team’s intended use. A total comparison and sample review are useful controls, but they are not a guarantee that every record or workflow detail was preserved. The cited product materials describe particular Dynamics 365 features; they do not establish a general migration method or prove that approval history, original attribution, or every date and duration survives a move [S1][S2].