diff --git a/docs/pagure2gitlab/gitlab.rst b/docs/pagure2gitlab/gitlab.rst
index 7743764..e50ad00 100644
--- a/docs/pagure2gitlab/gitlab.rst
+++ b/docs/pagure2gitlab/gitlab.rst
@@ -71,14 +71,54 @@ I tested this on `ARC project ticket <https://pagure.io/fedora-infra/arc/issue/5
       }
 
    This creates `comment <https://gitlab.com/testgroup519/arc/-/issues/1#note_1245817484>`_ on
-   the previously created issue. In this case the comment was created by user, who executed the
-   API call and according to API documentation it's not possible to change it.
+   the previously created issue. In this case the comment was created by user, who API key is used
+   to execute API call and according to API documentation it's not possible to change it.
+   We can overcome this by adding relevant information to each comment or issue. For example
+   the payload can look like this:
 
 
+   .. code-block:: json
+
+      {
+        "created_at": "2023-01-19T12:59:59Z",
+        "body": "(This comment was added by [t0xic0der](https://accounts.fedoraproject.org/user/t0xic0der/))\n\nHere's a sample comment as you requested @zlopez."
+      }
+
+
+Importing pull requests
+-----------------------
+
+To import the pull requests it's possible to use `Create MR API call
+<https://docs.gitlab.com/ee/api/merge_requests.html#create-mr>`_. However this doesn't allow
+us to open pull requests from any repository that is not hosted on GitLab. Following are
+the options that could be leveraged by the user for migration:
+
+1. Don't import any pull requests
+
+   This option makes the migration process much easier, but we will not have any already
+   existing pull request in GitLab at all.
+
+2. Migrate forks to GitLab as well
+
+   This will allow us to create pull requests from migrated forks of the original repository.
+   But this option means migrating plenty of git repositories, just to open the pull requests.
+   If this option is chosen, I'm recommending to only limit this to open pull requests on Pagure.
+
+3. Create branches on migrated repository
+
+   It's easy to open pull request from branch on the same repository, but this will mean that
+   tool will need to go through all the forks, add them as remotes and then add those as
+   local branches, which allows us to easily create a pull request. I don't recommend using
+   this approach as it needs plenty of adjustments on the migrated repository before the actual
+   migration.
+
+In addition to the issue mentioned above the pull requests will have the same issue with author
+as import of tickets. The author will be set to whoever generated the API key.
+
 Conclusion
 ----------
 
 Using the REST API v4 is not useful for our purpose, because it will set author of every pull
-request, issue and comment to user running the migration tool. This means that we will lose
-most of the information we want to preserve. Thus it doesn't make sense to continue in the
-investigation.
+request, issue and comment to user running the migration tool. This could be mitigated by
+adding the information directly to the pull request, issue or comment with link to FAS account
+of the user.