Migration tool mapping

Discussion in 'Using the new Kayako' started by Phil R, Jul 18, 2016.

  1. Phil R

    Phil R Established Member

    I'm thinking ahead right now and trying to understand / imagine how a migration may look.

    We can quite easily design from scratch how we think we would like things to look, but that obviously doesn't factor in the fact that we have not designed the migration tool and that what we expect is not strictly going to be what is delivered.

    Are you able to share any information on what the migration tool intends to do?

    You noted in the Webinar that it will map Departments to Case Forms. Can that be confirmed?

    How about User Groups, what function in New Kayako will they map to?
  2. Gary McGrath

    Gary McGrath Staff Member

    Hi Phil,

    I will get more information on this, but the migration tool is still being completed, so I don't have all the information yet. In terms of departments, we will be mapping those over as suggested, to ensure your existing flow works after migration. But there will certainly be many areas you need to update after migration. We are creating migration documentation on all this, which will be available once we enable the option.

  3. Phil R

    Phil R Established Member

    I need to understand if we need to plan in an upgrade on our current support desk, which I really need to start kicking off now to stand a chance of getting the relevant resource any time soon.

    Because of some forward planning requirements. Will there be a minimum supported version for the migration?

    Is that version released, or with a V4 release be upcoming to provide the needed functionality?

    I know specifics are not yet known, but if those questions cannot be answered at this stage into a August 15th release, then that sounds like a problem in itself.
  4. Gary McGrath

    Gary McGrath Staff Member

    Hi Phil,

    Our internal docs at the moment state "the latest version", so I think it is safe to assume this will be 4.74, as 4.75 will be released after we enable migration options. It is also possible that we might lower the version requirement, but this requires testing, which is what our engineering team are doing at the moment. We don't need a "fix" release.

  5. Gary McGrath

    Gary McGrath Staff Member

    Just to update you here Phil, the minimum version to migrate to the new Kayako will be 4.65 :)

  6. Phil R

    Phil R Established Member

    Much appreciated info.
  7. Phil R

    Phil R Established Member

    So, I noted the articles on this came out pretty silently.

    Regardless, having viewed them, they open a number of questions. I had thought of submitting a ticket, but I have so many direct questions open right now without response (not a concern currently), I didn't want to submit more.


    Going down the mapping side of things, it raised the following regarding out use case and quite frankly, likely cross-over for other peoples too in places.

    Email queues.

    This is a difficult one and also linked to a question I forgot to ask.

    We currently have one email queue per department. In some cases to email queues due to legacy reasons.

    These will be migrated in just fine, but I cannot see how to map an email address to either a Case Form or Team.

    This means that on each reply, I will have a list of all the email addresses and be forced to select from what is quite a lengthy list every time.

    Branding may take care of this for us going forwards, especially in a Partner type world. However, our existing and core use case will not have this extra factor limiting the association.

    SLA plans.

    This is where things get extremely scary for us.

    We have an extremely complex set of plans. Because V4 does not offer the third (next reply) metric that is referred to, we handle this ourselves and what is described looks like this is in conflict with the migration.

    1: General SLA question. When a case is first raised, SLA logic will allocate a plan (if applicable). When a customer replies, does a new plan get calculated from the rules?

    If so, they are 100% in conflict.

    We have a current SLA plan for new tickets and then a 2nd for non-new (2 plans). Then we have them by priority (*4 plans). Then by department (*x plans). Then by user group (*7 plans). To put this politely, that's a **** tonne of plans.

    The priority dimension is no longer needed, at V5 builds this into a single plan. However, the migration will not.

    2: Given that, does the migration merge plans?

    I doubt it, but worth asking.

    3: Will disabled plans be migrated?

    This could be scary. We have some disabled plans that are used manually. They are real legacy and something I want to drop.

    4: Overall, is there any way we can prevent the migration of SLA plans?

    Not to be funny, but our mess sounds like it would be even messier in a migration. There is a chance might be better starting all over again in a migration.

    However, to do that we would need to delete the old plans, which would leave us extremely vulnerable during the migration. It may take 4 hours to import, but it sure won't take 4 hours before we are running. So much so, I am not sure it may even be possible (and I highlight this as a point that there is no reward from the risk, thus could be considered as a prohibiting factor).

    SLA schedules and holidays.

    How exactly does this work, as what is quoted is physically impossible.

    For each schedule, a "Business hours" is created. That is a 1:1 v4:v5 mapping and is fair enough.

    It then states it will be linked with out "Staff teams". This is the impossible bit.

    According to the "Departments" migration, one team is created for each existing V4 department. V4 does not map a SLA Schedule to a department, they are just used by a SLA plan. SLA plans can apply to multiple departments.

    In our use case, we have business hours according to customer plans and not according to support operating hours. That means that for any given department in V4, tickets can be assigned to almost any of the 7 schedules we setup depending on the SLA plan rule hit.

    The problem here is, that in V5, a Business Hour can only be mapped 1:1 to a team in V5. So how do the newly creates business hours actually get mapped, because the description is either unclear, or simply impossible.

    Staff & Staff Teams

    The document completely misses out Staff & Staff Teams as migrated from V4.

    Given my questions above, I don't want to jump to the conclusion on how this will work.

    For one, our perpetual unlimited will now be licensed per staff member, so getting this right will be key.

    Time Tracking.

    Well, I can say up front, this has likely just lost our business.

    As much as other case metrics such as a average response times, number of touches and aspects of SLA are important, we are driven from the effort required as well.

    There are two aspects for this.

    1: Our Deployments area, in which we may bill time. It also helps understand similar case when performing effort estimates for new projects.
    2: Our Support area, in which we don't just look at case open time, but the amount of effort that goes into it. It also allows us to map effort on subject, allowing analysis into training requirements and even projections into resource modelling.

    The lack of time tracking and now the information that will completely lose this data, quite simply put tells us we should walk.


    It's plain and clear that the entire migration path has been centred around some very limited use cases. There is no flexibility and customer must make their environment conform to some extremely tight setup parameters, to make the migration move smoothly.

    To be clear, I don't envision the migration to be a "no effort" scenario. There are aspects that are simply incompatible and customers will need to think about how the new functionality works for their business rules (e.g. loss of notification rules).

    However, the level of effort prior to migration, and just as much effort post migration, means it's improbable we could migrate service in under 24 hours.

    It's almost as if you are missing a massive part of the solution.

    For one, why can we not sandbox our data, apply the customisation (which are going to take days, not hours), then import case & user changes.

    Essentially, no changes to SLAs, schedules, email queues, departments, teams should happen from the sandboxing. But users & cases can change, which are overlayed on top of the changes we have setup in the sandbox.

    Right now, I would need to go through an entire migration twice, each a unique one (even if the next does improve on the prior). I'm not sure we would want to afford such effort.

    It's almost as if it would be of an advantage to start from scratch with no migration. This gives us many more options, especially given the loss of metric data already applied.
  8. Gary McGrath

    Gary McGrath Staff Member

    Hi Phil,

    for email queues, you can assign a brand for each email queue within the email channel settings. You can also assign it to a team using automations ( example below )

    Screen Shot 2016-08-16 at 11.11.11.png

    RE SLA:

    We will import the SLA's you have, but for sure these might need tweaking, in your case, I imagine there will be several plans that you simply need to disable. The SLA applied to a case will not change on a customer reply, unless via automations other things are changed which then matches another SLA. e.g. change to status will not apply another SLA, but if you had a rule which said when status is changed to open, change the type to incident. Then an SLA looking at type = incident would apply.

    We will import disabled SLA plans, but these will import over as disabled too ( so you could as step 1 post migration, is delete all disabled SLA plans )

    Post migration, all teams will be linked to the default business hours, and you will then need to update the teams with correct business hours schedule. ( in your case, it sounds like you might also need to create more teams for it )

    RE staff and staff teams: We will import staff groups as teams, and add the relevant staff members to those teams. ( this is ok in tnk as a agent can be a member of unlimited teams )

    RE time tracking. this is coming, but it is not ready yet.

    I will pass on your general section feedback to the team on the limited options.

  9. Phil R

    Phil R Established Member

    Hi Gary,

    Regarding email, I am not sure I follow the example correctly. The automation are powerful, but that power may also create confusion, so wondering if this is just a simple case of that.

    Your example takes an email coming in on the mail channel, filter is by the destination recipient address (not declaring this the to address), If it matches, the case is assigned to a team. That seems a reasonably straight forward rule and replaces the inbound mail rules of V4.

    However, this isn't the problem I am trying to solve / query.

    Now this email is attached to a case (new/existing), an agent replies (not note).

    How is the "From" address selected in the list?
    I assume that it will only list those associated with the brand of the allocated Case Form (or any Case Form allocated to All brands).

    But, does it automatically select one from the list? This could be:
    * Last one selected in a prior agent reply
    * Uses the same value as the most recent recipient address of the inbound mail channel

    How does it determine a default selection?

    Just in general, we could not use the rule you provided, as we have determined we could not use Teams the same way as described in the migration path. Because of a combination of the way Teams & Business Hours work, coupled with our use case (use case being the way we sell support to our customers), we cannot map one team per department (Case Form).

    Regarding SLAs.

    What you have said certainly will give us a headache, but sounds manageable depending on circumstances.

    Importing our current SLAs will break us quickly. Our first response SLA is nothing like our next reply SLA.

    We would likely need to disable ALL SLA plans before generating the dump, so they are imported disabled.

    We can then generate fresh SLA profile post import that are enabled. Seriously, our plans could be converted from 300+ now to 5 plans (these are core plans, not some of the special side additions which can take their sweet time to be added / converted). That 300+ should be growing as well, and you can see with 300+ complexity, why it may not work well.
  10. Gary McGrath

    Gary McGrath Staff Member

    Hi Phil,

    The From address follows this in general:

    1. Use the last used from address
    2. Use the from address from the email queue the case was created from
    3. Use the default email queue.

    And yes, it will only list email queues based on brand

    RE SLA's, I have passed on the issues you faced to the product team ( from your other post ).


Share This Page