Should I migrate from ClickSoftware

The day is already late. A dispatcher can name the job that slipped, how long it needed, the skill it required, and the territory it sat in. Around the table everyone already agrees a second scheduler should be stood up beside the one the organisation already runs, and that the addition is a migration off ClickSoftware. The second box does not contain the duration, the skill, or the territory. The agreement is the problem. It is easy to reach, and it fits a new logo, which will schedule the same thin facts and call the result a project.

A late day is compatible with missing duration, a missing skill, a territory that was wrong, and a hub that already exists under more than one label. It is not, on these facts, evidence that a second engine is due. Only a repair of the three facts, inside the scheduler you already run, changes Tuesday. A twin engine adds a disagreement about whose day is real.

What follows are the questions that separate those explanations. Each has a good answer and a bad answer, and the difference is whether the answer names something specific: a job, a duration, a skill, a territory, a single hub. A general answer at this stage is what turns into a second box.

#1. Which job is actually in the room?

The question is not whether ClickSoftware should be migrated. It is which job made the day late, how long it needed, what skill it required, and which territory it sat in.

A good answer sounds like one late job, named by the dispatcher, with duration, skill, and territory written in the words that dispatcher uses.

A bad answer sounds like we are migrating off ClickSoftware. The sentence may be the title of the proposal. It does not name a job, so nobody will be able to tell afterwards whether Tuesday got shorter. A programme with no checkable job cannot be judged to have succeeded.

If any of the three facts is unknown, you are earlier than a migration. Stop. Ask the dispatcher. Write the answer they give. Then come back. People still say ClickSoftware because the word is on old contracts and old rollout names. The rebrand record says where that product went, and the sentence is quoted once: "Field Service Lightning, acquired from ClickSoftware in 2019, became Salesforce Field Service with the Winter ‘21 release."

The help page says the name the product carries now, and that sentence is quoted once: "Field Service is now Agentforce Field Service and Operations. In some cases, we still use Field Service to refer to this product area in Salesforce applications and documentation."

Read the two sentences together. Field Service Lightning, from the ClickSoftware acquisition in 2019, became Salesforce Field Service with the Winter '21 release. The help page now calls that product Agentforce Field Service and Operations, and it still uses Field Service in places. One hub, more than one label. ClickSoftware is not a second hub you still operate beside it.

#2. Which of the three facts was missing?

A migration that ignores duration, skill, and territory rebuilds a bad day even if it stays inside the hub you have. Moving the logo and dropping the three facts is the same mistake as adding a second engine. Duration is how long the job takes. Skill is what the worker must be able to do. Territory is where that work is allowed to happen. The scheduler produces a day from the facts it is given. If those three are missing or wrong, the day it produces is the bad day you already had.

A good answer sounds like the dispatcher pointing at one of the three facts and saying it was missing or wrong on the late job, with the corrected value written on that job in the hub.

A bad answer sounds like the inputs are fine and the engine is the problem. That may be what the proposal needs in order to sell a twin. It is not what the late job shows until the three facts are written. Call a correction a correction. Do not call it a migration off ClickSoftware. The name change already happened. The bad day is an input problem.

Count the jobs whose duration, skill, and territory are already in the scheduler you run. Those jobs are not a migration onto a new engine. Count the jobs where one of the three is missing. Those jobs are a data repair inside the hub, not a reason to buy a twin.

#3. Who owns the day, once?

Do not migrate off a scheduler you are already in. The field product is the scheduler. A project that starts from the ClickSoftware name, and ends by standing up another scheduling engine next to it, has added a second day. Two schedulers will disagree. The disagreement is how a bad day gets longer.

A good answer sounds like one box on the diagram, labelled Agentforce Field Service and Operations, with the late job's duration, skill, and territory written against it, and every other scheduling box crossed out by a named owner.

A bad answer sounds like we will run both until the migration settles. Both is two days. If a proposal cannot say which single scheduler will own Tuesday, it is not a migration. It is two plans. Send the diagram back until one box remains, and that box is the hub the help page names. A stay on that hub is the ordinary outcome. Do not carry the job into a second engine as a courtesy to the old name.

No second feature list, no travel formula, and no licence is invented here. The facts that change the decision are the hub you already run, and the three inputs a move has to carry.

#4. What does the hub already do with the facts it is given?

The native product is the field service hub those sentences name. It is the scheduler for the field day. Documentation may say Agentforce Field Service and Operations, or Field Service. Both labels point at that hub. The hub already schedules work. It does not need a twin in order to exist.

A good answer sounds like an administrator who can open the hub, show the late job, and say which of duration, skill, and territory the scheduler actually received.

A bad answer sounds like ClickSoftware versus Salesforce, with the three facts left blank. Versus native means: use that hub, and carry duration, skill, and territory. Adding a second scheduler fails the comparison. The native object already schedules. A second engine does not become more native by sitting nearer a logo. It becomes a rival day.

A move that copies appointments and drops duration, skill, or territory also fails. The native hub will still schedule. It will schedule the thin copy. You will recognise the thin copy because it looks like the bad day, with a new report title. The comparison is useful only after you have written what the hub already does. Then you can see that the work is to feed it, not to replace it.

Keep three lines apart. Hub: the field scheduler you already run. Inputs: duration, skill, and territory on the job. Forbidden: a second scheduler. A plan that cannot keep the three lines apart is not ready. There is no score.

#5. What is the plan using instead of the three facts?

The substitutes are an end date, a listing, and a second logo with empty facts.

A good answer sounds like a refusal, written by the dispatcher, of three things: an end date for the field product, a second scheduler, and an AppExchange listing as the engine.

A bad answer sounds like the listing will replace ClickSoftware. No listing is invented here. An app, a publisher, a review count, and a price are not in the records being cited. A listing found independently is still not the decision. The decision remains the hub and the three facts. An app that schedules is a second scheduler unless you have already decided, outside this decision, to leave the hub. That decision is not made here. The instruction is not to add a twin by accident. The field product was not given an end date. Do not treat it as a retired engine that a listing must replace. An AppExchange search will not restore ClickSoftware as a separate live product, and it will not fill in a missing skill.

Other field products exist. They are not ranked here, and they are not named in an order. A reader who wants a winner has asked for a judgement that is not made here. If a slide arrives with ranks, replace the ranks with the job, the three facts, and the single hub. A destination that is only a score, or only a second box, is not a destination.

There is no end date to remove from a notice, because no notice is cited. If a date is doing the work of the decision, the decision has not been made. The late job does not retire the hub.

#What staying actually looks like

All five answers are measured against an alternative, and the alternative is usually left unstated, which flatters the second logo.

State it. Staying means Tuesday is scheduled in Agentforce Field Service and Operations, with duration, skill, and territory written on the job, by the dispatcher who already knows which job slipped. The word ClickSoftware remains on an old contract. That is a label. The day is not. The cost of a false move is two schedulers and the same late afternoon, now with an argument about which board is right.

There is a version of staying that is simply the correct decision. If the three facts can be written, the hub you already run is the whole answer. An organisation that repairs the inputs first reaches any later conversation with a shorter day and no twin to reconcile.

A good answer sounds like a list of late jobs, each with duration, skill, territory, and one hub, produced by the dispatcher rather than by the owner of the second box.

A bad answer sounds like we cannot keep the old rollout name. The rollout name can sit in a footnote. The scheduler does not get a twin because a footnote is old.

#Where the neighbouring questions live

What it costs to change a job you have actually described sits on the ClickSoftware implementation page. The acquisition and the names as history sit on what happened to ClickSoftware. The objects, and what you do when a job does not land on the board, sit on integrating ClickSoftware with Salesforce.