New Scrum Master trying to Implement Scrum

Best thing would be to either hire experienced Scrum coach (for example people who advertise their courses at Scrum.org) who would teach basics of Scrum to everyone involved, or, even better to start learning Scrum by your own, whole Scrum team together(very carefully reading Scrum guide is a first step) and then implementing it as you learn.

What you do now is not Scrum, but that's okay, considering you all are only starting.

Add learning scrum into product backlog and definition of done, and and encourage developers and product owner to always select some learning items into Sprint backlog for upcoming sprints.

Learn from mistakes.

You used a lot of scrum terminology but it wasn't used according to the Scrum Guide. For example, the Product Owner does not estimate the size of work, assign work or even decide what will be in the next Sprint.  As you explain it, you are using time based cycles in a waterfall project where one person is in control of the work that everyone does.

I am not sure where you are doing your education on Scrum.  Some of your understandings are vaguely correct but not the implementations.  I would suggest that you read the Scrum Guide multiple times.  It really isn't that long and reading multiple times helps you to connect information that is stated within. 

Currently, I have been tasked by the Product Owner to figure out how to migrate the business users' tickets to Jira while keeping the dev teams' tickets on GitLab. After the business user tickets are separated from the developer tickets I can then start implementing the Scrum framework in the team.

Why is this necessary?  The Product Backlog is expected to hold any work that is needed in order to improve or maintain the Product.  Aren't the Business Users tickets potential work that is needed? And what authority does the Product Owner have to assign you work?  According to the Scrum framework, they do not have this.

I am going to suggest that having a Chief Technical Officer as a Product Owner is probably not a great idea.  The position of CTO has a lot of authority that comes with it.  I could be wrong, especially if this individual is willing to give up that authority and give the Scrum Team the ability to self-organize and self-manage their work to the benefit of the Product. But given the statements you have made, it doesn't seem to be the case. 

As a Scrum Master, it is your responsibility to ensure that everyone in the organization understands and appreciates the Scrum framework, not just the Developers.  I would start with the CTO and help them understand the framework properly.  Find out if they are willing to change the command-control structure in place today to allow Scrum to be effective.  Find out what they expect to see from a change to Scrum.  You may find that all they really want is to use some of the terminology so that they can claim they are Agile.  Agile is not a framework, process or methodology. It is a commercial concept that allows companies to make money by selling products, services, tools that are touted as helping companies.  However, if they really want the company to have the agility to adapt to changes and incrementally deliver products, Scrum might be a good choice for them but only if they are willing to give up the command-control environment they have established.

Based on this information, how would you go about implementing the Scrum framework 

You wouldn't. You wouldn't implement Scrum based on those issues you've described. Scrum isn't something to be molded and twisted around what an organization does right now. Instead, the framework is about changing that current reality so very different empirical outcomes can be achieved, each and every Sprint.

Bear in mind also that it isn't your organization to change in the first place. Find out who in the company wants Scrum as it is actually defined in the Scrum Guide. That's what everyone''s understanding of Scrum really ought to be based upon. Find out who wants different outcomes from the ones they are currently getting with the "distribution of work" you have described, and who can create a sense of urgency for the necessary change to happen.

Good points already mentioned.

Appologies, not trying to be rude. Only from similar questions before, I get the notion the question is, how do I put the team into the scrum box? It seems an attempt to implementing scum by identifying the set of scrum rules, and force them on a team with a traditional command and control project management style. 

I believe one aspect is to have the team part of the discussion. Instead of telling people what to do, tell them what not to do. For example, PO sets up priority on backlog, and team pulls from the backlog. No assigning of tasks.

POs are not suppose to assign work to the developers. Developers are suppose to pull work from the Product backlog because the Developers can self manage.

The Product Owner is responsible for determining what goes into each release. They receive updates on new issues from the System Administrator twice a week, unless it's an urgent matter. The Product Owner recommends solutions, estimates the effort (weight/sizing), adjusts the priority of tickets, and assigns them to developers they believe can complete the tasks. They may also assign other developers to a ticket to gain a better understanding of the issue or to seek their recommendations.

Scrum team needs to be clear on their roles and responsibilities as provided in the scrum framework.

PO should prioritize task as he is doing already but here he is also controlling dev team by dictating how the work to be done.

There should be backlog refinement session where the PO should recommend solutions, share and clarify the dev team on the priority tasks and answer any queries the dev team might have. The assignment of each task should also be done in the same meeting in discussion with the dev team and if the team identifies any task on which external recommendations are needed the dev team should reach out to the concerned other developer and call out if any support required from the SM or PO. The great scrum team are autonomous, empowered, trans decent, and cross functional.

Assigning tickets first and then the team coming with input, will add unnecessary confusion, lack of transparency, rounds of discussions and meetings , silo discussions which is not the essence of SCRUM framework.

Currently, I have been tasked by the Product Owner to figure out how to migrate the business users' tickets to Jira while keeping the dev teams' tickets on GitLab

This is not the responsibility of the SM though. 

Also the product owner wants the meetings with the Product Owner and System Administrator to be replaced with the Scrum Master and the System Administrator which doesn't makes sense to me.

Looks like he wants you to share his workload, again you can be part of this meeting to have an idea of what the future sprint goals and task will look like but replacing is not a good idea. You need to coach the product owner and give him some clarity on the scrum team jobs and responsibilities. Looks like the way he is thinking to get the work done is broken and he has no idea of how the SCRUM framework works. You may conduct workshops and discuss it out with other SMs in the company to understand. OODA way of working is to be followed here- observe, orient, decide and act. Just assuming will not work here, you need to act.